One last point before I shut up: If there would be another widget supporting the Format interface it would make sense to have a dedicated interface. But then again it would make no sense to pass a DateBox as this ties the Formatter to this particular widget. If there would be a abstract Format interface with parse() and format () the DateTimeFormat would be a perfect candidate for implementing this. This would enable users to come up with simple implementations if you this DateTimeFormat is too complex. If we do not decouple DateBox and DateBox.Format it is just adding unnecessary complexity IMO.
On Jan 13, 7:10 pm, dflorey <daniel.flo...@gmail.com> wrote: > I know this is nitpicking, but some comments inline > > On Jan 13, 6:53 pm, Emily Crutcher <e...@google.com> 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 <daniel.flo...@gmail.com> 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 <rj...@google.com> 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 <daniel.flo...@gmail.com> > > > 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 -~----------~----~----~----~------~----~------~--~---
