> No build in 2 way support (that i was trying to fix)
What do you mean?
if i change the field by hand (i type in another year)
then when i press the show calendar button it should ofcourse use that
current value of the field.
No Localization
The localization you get is just a couple of language filled in by
default. Very nice, but are you sure it'll work for Chinese and
Russian etc? And are those languages gonna be maintained properly?
(the problem with that other project)
But the strings are very easy to add its just a few lines javascript and it
aren't to many strings.
So i can synch up with that project when he does (when i send him my
changes)
or let others contribute to our own project. I don't mind. But this is the
case with all
datepickers that we would choose.
Loads and Loads of javascript that you need (difficult to read)
Difficult to read? It's one of the more decent API's I've seen. It's
funny when you work on Wicket while at the same time seem to have a
problem with other projects writing very generic code.
its one large javascript file with all kinds of constructs and callbacks to
each other
hopefully if they really can make a nice javascript editor in eclipse that
can find references (and call hierarchy)
then that would be easier to read. If find the goodies one much easier to
read and to understand.
I had that one running fine in wicket within one hour and i have now spend a
few hours implementing AM/PM support
(which also works now for the large part including the date format parsing)
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)
But you can do that with the selectHandler like DatePicker does. Why
does that have to be a built in facility?
Then 2 way doesn't work. Just try whats now in svn. Switch to german and try
to change the date a few times
it goes wrong because the selectHandler is the wrong kind of implementation
(its a hack). It does only one way
(selection -> textfield) the other way should also work. So what should be
done is setting all the right
properties for the format string. If we can handle that parsing (preferable
in java) then this is no longer a problem.
Can Joda time now give use the right information? Like what is the the
DateDelimiter? then we just have
to parse it a bit more and ask what the positions is of the D M Y values. So
we can generate it correctly
and also don't need (or shouldn't need) the selectHandler.
> 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)
So it's probably a CSS problem, that likely can be fixed at your side.
that seems to be seen if that is easy. Because i can't make the div greater
of the datefield itself
and if the div of the popup always wants to reside in the div of the
datefield then i have a problem
If i made the datefield large enough to hold the datepicker then it works.
Look, it's fine when you look for something very concrete and stuff. I
completely do not agree with you bashing this component though. I
think it's very well written, and - if you take the time to figure out
how - the sky is the limit with that component (custom events, custom
renders, etc).
I did look at it extensively because i needed to see how to do the parsing,
if it was possible to quickly change the year (this is for me also a big
showstopper)
and how to enable 2 way support.
But hear this:
1) I did NOT intend this to be THE datepicker of choice for Wicket. I
asked for others to contribute, but a contribution never came. The old
one - also the result of my blood sweat and tears - was painful to
maintain. Yes it has all kinds of languages, but at least 30% of them
didn't work well. It rendered ugly and slow, and the code wasn't
particularly pretty to look at. But the nbr 1 problem was that it
wasn't being maintained at all. The YUI calendar is a professional
looking widget of which I'm pretty sure it will be maintained for a
long time. Surely it's not perfect, like none is, but hey, just build
your own one then. For Wicket, the YUI calendar is a good choice, and
things like localization and even things like year selection and stuff
can all be build in if we create the proper abstractions.
Its a nice component i am not disputing that it has many functions and so on
only many of those functions i really don't need.
i need time, fast year selection, and as good as possible datetime format
parsing.
So i can't really use it (besides my css problem)
I think the parsing we can build in java and then setting all the right
properties.
But the first 2, time and year, will be pretty hard because there is no
support what
so ever for that in the javascript (at least what i can find) so for that i
would need
to really change the javascript code of YUI itself big time. And that is not
what we
want because then we are out of syn. And that is for this big scripts pretty
bad.
Biggest problem again is LGPL :( so it can't be added to core. I will make
a
> wicketstuff project.
Yeah, let's all just commit our own favorite date picker. Are you sure
you gonna support it well?
yes because this one will be used by Servoy.
I still hope that that i can convince him to do a dual license because then
i can just add a goodies package in the current datetime project and people
have a choice
for 2 datepickers depending on what they want and which look they like.
johan
