I copied large pieces of code from the YUI datetime project and made my own project around the one from http://www.dhtmlgoodies.com/
How more i looked at the YUI how more i disliked it . No time support, No fast year switching support, Strange selection support where you have to set 2 things (selected date (day/month/year) and selected page (month/year) No build in 2 way support (that i was trying to fix) No Localization Loads and Loads of javascript that you need (difficult to read) And i still can't find or know how to config a date pattern... (none of the examples show that and i can't find the javascript that does that) just look at the setupConfig part in the javascript, there is no property like datepattern, or just search for DATE_DELIMITER, it isn't set (what the parsing should do) anywhere in the code (except in init), . So the parsing of the (java) format strings has still to be written to look what all the positions are and what the delimiter is. beside all that, it still doesn't work correctly at my place when using css positioning I guess that had something to do with the div that you needed to include in your code that is then encapsulated in a div where it then resides in and it can't grow bigger then that div (if this is the case then that is problem for us) Ofcourse it has many more functions (like rolling/setting date properties and so on) but i don't need that really in a wicket calendar component or multiply months at once (also don't need that i need fast year switching), multiply select. The one from dhtmlgoodies is pretty nice and has pretty much all the features i need. (like real support for almost any kind of datetime formats) Fast switching of years, time support, localization is done for the major languages (and easy to maintain), it is 2 way. Biggest problem again is LGPL :( so it can't be added to core. I will make a wicketstuff project. Also it doesn't seem to have support for AM/PM i guess i will need to build that my self. johan On 3/27/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 3/27/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > ok that is fixed. > But i will give up currently on the YUI Calendar because it really doesn't > play nice for me > with Localization and my own dateformats. > The calendar should work 2 way (if i change the input field itself and then > popup the calendar that change should be noticed) > that is what i pretty much have working now for the English locale the big > problem is the how to do that with YUI? > Its impossible it seems because you can't call a simple method or set a > property where you set the dateformat. > If i read this correctly: > http://developer.yahoo.com/yui/examples/calendar/germany/1.html > > then it seems you can only configure this by setting all kinds of > properties, this is horrible because then we have to > parse the format complete and set those properties based on what we find. > (and translate it all!) YUI has a constructor based mechanism too. DatePicker uses that; see configureWidgetProperties. But I actually think their property based approach is pretty good, as it is more flexible and more readable than a constructor based approach. And as we're writing a component on top of it, why would you care? Just abstract it. And yes, the translation still has to be done. The old datepicker had translations, though they were poorly maintained (like the whole widget was). > It is such a shame that this kind of calendar is again in LGPL: > http://www.dhtmlgoodies.com/scripts/js_calendar/js_calendar.html > > Looking quickly at the code is exactly what i want: > > displayCalendar(document.forms[0].theDate,'yyyy/mm/dd',this) > > > you set the dateformat directly in the displayCalendar call.. Thats how it > supposed to work But it probably not nearly as flexible, and I like both the look and feel of the YUI calendar much better, like I like it better than the old one. > Also what sucks a bit for the YUI calendar is that it is very hard to switch > quickly over the years. > (what if i use it for a birthday selection that can be something between > 1960 and 1990, that horrible in that calendar) > > So i guess i have to use the old calendar we had, that was much better > suited for us but if anybody > knows a calendar like the one above that is not (L)GPL but a apache > compatible one please let me know. Seems to be a hard one to get right. I've investigated quite a few and YUI was and is the only one I really like for both the look and feel and the API. It's also one of the few libraries you can pretty much count on on being maintained, which was a problem for jscalendar and probably for just about 80% of Javascript widgets out there. Hard to please everyone though, so sure, if you prefer the older one, go for it. Or you can keep working on the proper abstractions so that everything you don't like about it is hidden in our component(s). Eelco
