click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Demetrios Kyriakis <>
Subject Re: DateField license issues
Date Tue, 25 Nov 2008 20:05:19 GMT
>> 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 

>> 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 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.


View raw message