I looked at the Yahoo components and I like them a lot. I started working on a yui (Yahoo UI library) package in extensions, an example in wicket-examples, and picked Calendar as the first component. It's very crude still, but it looks like that yahoo stuff is going to save our day :)
The only thing I am lacking is time. I am enclosing what I worked on (it's in CVS too, but it'll take a few hours to show up) and I am hoping on some participation. First step is to look at what I did, and think what way you'd like it to evolve. Of course just a patch to make it work in a form, have CSS styles work properly and an extension, DatePicker that let's you select a date and put it in some other field is more than welcome too! ;) Or the tree. Or... Eelco On 2/24/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Hi all, > > There's a bunch of problems with DatePicker poppin up. In fact, there > have been problems with it's localization support from the start, but > I hoped they would be fixed with a new version of jscalendar for which > the datepicker component is just a wrapper. However, the last release > of that thing was almost a year ago, and I don't feel confident there > will be any release soon. > > I'd like to propose an alternative to jscalendar. One that has > robusteness over number of features, though I have no problem with > that thing looking nice. > > One of the candidates that looks good to me is the yahoo calendar, > http://developer.yahoo.net/yui/calendar/index.html Anyone played > around with that? If that's good, and some other yahoo components are > too (they sure look good to me), we could create a couple of > Yahoo/Wicket components. My plan would be to deprecate the current > date picker - fix bugs if anyone can submit patches, but I'm too short > of time to go after that myself - and create a > wicket.extensions.markup.html.yahoo package for all yahoo components > (e.g. we would have wicket.extensions.markup.html.yahoo.calendar). > Also, my plan would be to make using these components super easy to > use. If I look at the current DatePicker implementation, I believe I > took it too far in trying to support a large part of the jscalendar > API. New implementations should be far simpler and more limited to > what it can do by default. If people want more fancy stuff, they could > extend such a component and learn from the implementation how to take > their component further. > > Thoughts, suggestions? > > Eelco >
calendar.renametozip
Description: Binary data
