Rob Desbois wrote:
I disagree; in the interest of keeping the plugin small, to do this
outside the class is equally minimal effort and I don't think the plugin
should accept every possible representation. If you always use Date
where String is required, you can overload and wrap the function to
perform the conversion.
I agree :)
Kelvin:
That said I think that given it's a *date*Picker, Date would be a far
more appropriate choice for the interface than String. What made you
choose String?
In this instance I chose date to be consistent with dpSetStartDate and
dpSetEndDate. I'm not 100% sure why I originally chose strings for those
method's arguments... One possible reasons is because a string contains
only date information (no time information). When I convert it to a Date
object I convert it to midnight of that day and this is the specific
date/time that is used for all comparisons. If you passed in a Date
object I would need to .zeroTime it to make sure all the comparisons
worked and avoid any possibly hard to track down bugs... Possibly not
the best reason in the world, I'm open to suggestions if people feel
there is a good reason to change it...
Thanks for the feedback,
Kelvin :)
--rob
On 6/6/07, *Brian Miller* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
Just my opinion: both Date and String should be supported. It's
probably
only two lines of code to check for type, and cast to the other type if
necessary.
- Brian
