I know this is nitpicking, but some comments inline On Jan 13, 6:53 pm, Emily Crutcher <[email protected]> wrote: > Daniel, > > You have some good points and what you are describing is almost exactly > the date box we initially had in gwt-incubator. We ran into a few > significant problems that made us change to the current design: > > 1. DateTimeFormat represents a very sophisticated API, it was difficult > for users to replace the formatting/parsing of dates because, to do so they > needed to understand the internals of the date time format class.
I don't see the difference. If we would get rid of the Format interface we would end up with 3 cstrs: DateBox() = same as now DateBox(Date date) = same as above, but with initial date set DateBox(DatePicker dp, Date date, DateTimeFormat format) = for advanced users that want to specify the format It's even simpler than it is now where I have to write new DateBox(new DatePicker(), new Date(), new DefaultFormat (DateTimeFormat.getShortDateFormat()) to change the format instead of new DateBox(new DatePicker(), new Date(), DateTimeFormat.getShortDateFormat()) > 2. The most desirable default parsing behavior was a hybrid between a > DateTimeFormat + a fall back to the browser's own parsing algorithms, this > could not be cleanly modeled using just the DateTimeFormat. Where can I find this browser's own parsing algorithms in the current code? > 3. When we used a template method to allow users to override the error > reporting for date box, we still got a lot of people not finding it, as the > typical users looked for a setter of some flavor. > I guess for 99% of usecases the default behaviour of applying an error style to the date box is sufficient. The 1% of usecases that want to do more sophisticated error handling should be able to override the parse() method and catch the exception. If I want to do my own error handling right now I have to: Implement my own Formatter or subclass DefaultFormat anyway and implement/override the parse method and I don't see why this is any better than just subclassing DateBox. > > > > > On Tue, Jan 13, 2009 at 11:49 AM, dflorey <[email protected]> wrote: > > > Seems to be a matter of taste ;-) > > If parse() and format() should be capable of sophisticated error > > handling (like triggering a popup to show the error or whatever) I'd > > prefer to simply implement them as protected methods in DateBox + > > passing DateTimeFormat to cstr instead of Format interface and let > > user customize the behaviour by subclassing DateBox. > > I just wanted to report that it looked strange to me at first sight > > and as I'm totally average this also could confuse others... > > > On Jan 13, 5:36 pm, Ray Ryan <[email protected]> wrote: > > > DateFormat isn't just a parser, nor even mainly a parser. It lets you > > > customize the display of your datebox in response to bad input. And > > because > > > we pass DateBox in as a parameter, your DateFormat can be a shared > > > flyweight. > > > rjrjr > > > > On Tue, Jan 13, 2009 at 8:08 AM, dflorey <[email protected]> > > wrote: > > > > > Hi, > > > > I'm for the first time using the new 1.6 DateBox.Format feature and I > > > > wonder why I have to pass a DateBox to the format() and parse() > > > > methods. > > > > The DateBox is used in the parse method to display parsing errors. > > > > I would prefer to let parse() throw an IllegalArgumentException when > > > > parsing fails and catch this exception in the enclosing parseDate() > > > > method. This would clean up the DateBox.Format interface. > > > > > If you agree I can provide a tiny patch... > > > > > Cheers, > > > > Daniel > > -- > "There are only 10 types of people in the world: Those who understand > binary, and those who don't" --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
