Hi all,
For those who don't know, Joda Time: http://joda-time.sourceforge.net/
is a *much* better replacement of the Java date and time APIs it many
ways (see their 'why Joda time section'). Also, Joda time will be the
basis of JSR 310 (http://jcp.org/en/jsr/detail?id=310).
Date/ time handling w
My non-binding vote is go for it.
Eelco Hillenius wrote:
Hi all,
For those who don't know, Joda Time: http://joda-time.sourceforge.net/
is a *much* better replacement of the Java date and time APIs it many
ways (see their 'why Joda time section'). Also, Joda time will be the
basis of JSR 310 (h
exactly what will you improve in core by having joda time? why cant it be a
dependency on the extensions? or why not make it a core module all onto
itself?
-igor
On 2/2/07, Philip A. Chapman <[EMAIL PROTECTED]> wrote:
My non-binding vote is go for it.
Eelco Hillenius wrote:
> Hi all,
>
> For
-1
I'm a big fan of joda time, but i think this should really be an
"extension". even if it is better than the core wicket binder, 1/2MB is a
large addition to any project.
On 2/2/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
exactly what will you improve in core by having joda time? why cant
On 2/2/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
exactly what will you improve in core by having joda time? why cant it be a
dependency on the extensions? or why not make it a core module all onto
itself?
The most important reason for that is that we could ship the core
project with a dateco
even if it is better than the core wicket binder
It's not just better, the current date converter is just wrong/ naive
imo (though this is a problem with most if not all competitors as well
in suspect).
Eelco
I'm all for using something that actually works. =)
On 2/2/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> even if it is better than the core wicket binder
It's not just better, the current date converter is just wrong/ naive
imo (though this is a problem with most if not all competitors as
+1 (non-binding)
I am using the joda-time package myself. Except for the datepicker I have
written al date components/date converters myself using this package because
it gives me so much more options without any bashing or hacking.
It is so easy to use the timezone and Local support that is bu
why is it so big? complete wicket is 1.5 so only some date manipulations are
1/3th?
johan
On 2/2/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Hi all,
For those who don't know, Joda Time: http://joda-time.sourceforge.net/
is a *much* better replacement of the Java date and time APIs it many
And jar size doesn't really matter on the server, does it? I find that
argument pretty much a non-issue.
I don't like the fact that we are going to depend on a library and
find out that in Java 7 it is no longer necessary (it is now a JSR).
The problem is that they are not rubberstamping Joda but
-1 for core
+0 for extensions
+1 for a wicket-joda core module
extensions is getting pretty big, its hard to find things. if i am using
joda in my project and see wicket-joda i immediately know what it is and i
can easily browse the contents and only see things that interest me.
-igor
On 2/3/0
good idea. similar to the wicket-spring module.
On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
-1 for core
+0 for extensions
+1 for a wicket-joda core module
extensions is getting pretty big, its hard to find things. if i am using
joda in my project and see wicket-joda i immediately know
It is so big because it contains a snapshot of the tz database.
Regards,
Erik.
Johan Compagner wrote:
why is it so big? complete wicket is 1.5 so only some date
manipulations are
1/3th?
johan
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
Ok, what about this: we create wicket-datetime, which depends on Joda
time, and includes all the date/ time nifty stuff we can come up with,
including the dreaded date picker?
Eelco
On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
-1 for core
+0 for extensions
+1 for a wicket-joda core modu
+1
although almaw is working on his datepicker, and the one in wicket-stuff is
prob 75% there, so we should have a good replacement rsn :)
-igor
On 2/3/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Ok, what about this: we create wicket-datetime, which depends on Joda
time, and includes all
On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
+1
although almaw is working on his datepicker, and the one in wicket-stuff is
prob 75% there, so we should have a good replacement rsn :)
That would be cool, and I think a good match for that project as well.
Might be easier to find and stuf
Eelco Hillenius wrote:
On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
+1
although almaw is working on his datepicker, and the one in
wicket-stuff is
prob 75% there, so we should have a good replacement rsn :)
That would be cool, and I think a good match for that project as well.
Might
On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
+1
although almaw is working on his datepicker, and the one in wicket-stuff is
prob 75% there, so we should have a good replacement rsn :)
I just took a look at the one in wicket-stuff (trunk only, as in the
branches the project with the same
+1 (non-binding)
Eelco Hillenius wrote:
>
> Ok, what about this: we create wicket-datetime, which depends on Joda
> time, and includes all the date/ time nifty stuff we can come up with,
> including the dreaded date picker?
>
> Eelco
>
>
> On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
On 2/3/07, Al Maw <[EMAIL PROTECTED]> wrote:
Eelco Hillenius wrote:
> On 2/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>> +1
>>
>> although almaw is working on his datepicker, and the one in
>> wicket-stuff is
>> prob 75% there, so we should have a good replacement rsn :)
>
> That would be coo
Eelco Hillenius wrote:
Al, are you seriously working on date picker you want to contribute to
Wicket?
Yes, but it's really not very far along yet and I don't think we should
hold up 1.3 for it (certainly not the first beta at least).
It's relatively easy to make a datepicker if you have eith
On 2/3/07, Al Maw <[EMAIL PROTECTED]> wrote:
Eelco Hillenius wrote:
> Al, are you seriously working on date picker you want to contribute to
> Wicket?
Yes, but it's really not very far along yet and I don't think we should
hold up 1.3 for it (certainly not the first beta at least).
Cool. We do
One of the issues with the old one was that it depended on the date
format that was used by the date converter(s). It is/ was pretty ugly
actually. It would be great if we would have a way to get the pattern
that will be used for input/ output for date, time and number
converters used by a compon
the one i started in wicket-stuff works a bit different afair.
it has javascript that can parse simpledateformat expressions. so you give
the expression to the component - or it gets one out of locale, whatever,
and then passes it to the javascript. so it stays in sync that way.
-igor
On 2/4/0
isn't that how it is done with the old datepicker?
it gets the format out of the converter
Yeah, with this code:
if (dateConverter == null)
{
// TODO this should be much easier and nicer to do in
2.0
IConverter typ
and where does it get the expression from?
You give it to the component? So when you say: setFormatString(String) you
also initialize the dateconverter?
That would be a bit better yes. If the component just makes the converter
instead of getting one and then extracting the string.
johan
On 2/4/
On 2/3/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Ok, what about this: we create wicket-datetime, which depends on Joda
time, and includes all the date/ time nifty stuff we can come up with,
including the dreaded date picker?
I went ahead with the project and committed wicket-datetime in th
On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Martijn/ Frank, I think I got all the headers, notices and patch to
wicket-parent done ok and testing building the whole bunch. But if one
of you could double check please...
* You have included the license header test but not executed it?
On 2/5/07, Frank Bille <[EMAIL PROTECTED]> wrote:
On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> Martijn/ Frank, I think I got all the headers, notices and patch to
> wicket-parent done ok and testing building the whole bunch. But if one
> of you could double check please...
>
* You h
So do
I just instantiate the appropriate arrays (like cssIgnore) to mark
these Yahoo files to be ignored?
Ok, ok, I should read first, than ask. Answer is yes.
Eelco
On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> So do
> I just instantiate the appropriate arrays (like cssIgnore) to mark
> these Yahoo files to be ignored?
Ok, ok, I should read first, than ask. Answer is yes.
Yes! :)
Frank
On 2/5/07, Frank Bille <[EMAIL PROTECTED]> wrote:
On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> > So do
> > I just instantiate the appropriate arrays (like cssIgnore) to mark
> > these Yahoo files to be ignored?
>
> Ok, ok, I should read first, than ask. Answer is yes.
>
Yes! :)
A
On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Actually, maybe not :) I tried:
cssIgnore = new String[] {
"src/java/wicket/extensions/yui/calendar/assets/calendar.css"
};
"src/main/java/wicket/extensions/yui/calendar/
On 2/5/07, Frank Bille <[EMAIL PROTECTED]> wrote:
On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> Actually, maybe not :) I tried:
>
> cssIgnore = new String[] {
>
>
"src/java/wicket/extensions/yui/calendar/assets/calendar.css"
>
I normally just copy the string from the console output of the unit test
(without the prefix)
Frank
On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 2/5/07, Frank Bille <[EMAIL PROTECTED]> wrote:
> On 2/5/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> >
> > Actually, maybe not :) I t
35 matches
Mail list logo
