1. Keep the DateField API (the public Java one), but "refactor" the
render method, to be like the RoR date field - the one with comboboxes.
(it's not that fantastic, but it's usable, and is breaking no
application code).
If we keep the DateField I suggest we just leave it as a textfield.
Using selects seems like trouble e.g. how many years should there be.
What about Date+Time. Using a textfield there is no way for the old
values to corrupt.
JSCalendar also did not supported all years (I guess only starting from
the '70
till 2050.
The problem I experienced with "pure textfields" for Date/Time values,
was that the users got shocked when they saw it, since they always typed
the wrong format, or what they were used to(e.g. in some applications
even words were allowed: tomorrow, next week, etc.).
I think with a little javascript it is possible to make the selects
not corrupt values, and still have a great user experience (taking a
look at the RoR example might help - it works pretty good for many
applications).
2. Move the JSCalendar to a component called "Calendar(Field)" - since
this is the correct name for it since it displays a calendar in that
popup. It's API could remain the same as it is now, and the package
too (the sf.net.xxxx) to ensure maximum compatibility with existing
applications too.
Nods CalendarField sounds good.
Maybe a new page could be added to the Click site: "Wanted" :),
where various important and "wanted by the Click project" would be
listed (most users won't look in the JIRA to see the feature requests,so
they're more for the developers).
The first item could be:
"Apache licensed javascript calendar similar to JSCalendar".
This way, maybe occasional visitors, propose/deliver a better solution.
Demetrios.
