JQuery and YUI has nice Calendars but this creates at least two problems:
#1 Forces on users a specific Javascript library
#2 JQuery and YUI Calendar file size is much larger than JSCalendar.
Besides, those two frameworks are not allowed in many projects.
From the looks of it other Apache frameworks also tried to integrate
JSCalendar but could not get past the license issue. Howard Lewis Ship
from Tapestry fame logged a request with JSCalendar to adopt an Apache
friendly license but to no avail.
We'll have to make a decision on how to proceed.
One option is to remove DateField from Click and host it externally at
Google code. This is pretty much what Struts 2 had to do as well:
http://cwiki.apache.org/S2PLUGINS/jscalendar-plugin.html
I think we can do better :).
I do realize that this will break most Click application out there but
there are a few things we can do to alleviate the pain.
#1 enhance the ant script get-deps to download the click-jscalendar.jar
#2 document clearly that the DateField is hosted externally with links
to its binary jar.
#3 upload click-jscalendar.jar bundle to our existing maven2 repository.
Any other suggestions?
I think there are a few steps that could be taken to make things work:
(and they were proposed by users long time ago on the click lists)
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).
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.
3. Hosted outside of Apache.
4. Document, and make it usable/available like you described above.
This way, the code will work as before for everybody without braking,
and if some users have the problem that it's not "that calendar", they
can do those steps you mentioned.
So basically instead of "removing" it, it would be just refactored to a
new component :).
Thank you,
Demetrios.
P.S. #5. Propose for the next google summer of code a project for a
library like JSCalendar but with Apache license (many of the proposals
of this year from Apache were not to helpful, but this one could really
be, since other Apache projects would need it too).
