Eelco Hillenius wrote: > > On 2/15/07, ChuckDeal <[EMAIL PROTECTED]> wrote: >> >> I was trying to use the datetime.DateTextField and it was giving me a >> little >> grief when I was trying to use DateTime objects with it. It was my >> understanding that that datetime project was to be built around the joda >> package. Here is a patch the removes the java.util.Date "stuff" in an >> attempt to be a pure DateTime converter. >> >> With the following patch in place, my code works properly (ie, no errors >> parsing or returning dates). Let me know if I'm on the wrong track here, >> please. > > Hmmmm. Yeah, I can see your point. My - original - idea was to use > Joda-time internally and have this thing work for normal > java.util.Dates transparently. > > I think the best way to do here is to create another converter, the > other one being fully based on joda time and build a separate text > field for it etc. I definitively want to support normal dates, but I > realize it's quite logical to expect wicket-datetime to work with > joda-time all the way as well. > > What do you think? > > Eelco >
I suppose that if the current DateConverter became DateTimeConverter and a new DateConverter used DateTimeConverter to get a DateTime object then return toDate() from that it should be fine. Did you get all that? Anyway, I do see where you were going. Let's assume that the datetime package was to be as close to pure jodatime as possible. Supporting util.Date shouldn't be that hard or complicated because joda pretty seamlessly wraps that utl.Date. But for clarity, where would we actually need to support util.Date? In the setting of an object and in the getting of the object (for persistence, etc). The model/converter should take care of most of the work "under the hood", right? Setting should be no problem because DateTime can easily wrap the util.Date, so no extra code needed in the Converter. It's the getting that could be problematic because if the underlying Model wants a Date, we would need to use the toDate() method, but when would it be called? So, as an end user, what could I do to use the "better" datetime package while still utilizing my legacy data structures (util.Date) without the wicket devs adding a bunch of crap into the datetime package? <gets sidetracked with something else, comes back, curses, then says...> I don't remember where I was going with that, but I hope you get the idea. Chuck -- View this message in context: http://www.nabble.com/-datetime--DateConverter-tf3233793.html#a9041780 Sent from the Wicket - User mailing list archive at Nabble.com. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
