There is an effort planned for next quarter to create the global date binding/error handling/etc. solution. The problem is that is that we wanted to introduce a usable date box this release, not next, so we created the interface that would be least likely to clash with a global solution.
On Tue, Jan 13, 2009 at 1:16 PM, dflorey <daniel.flo...@gmail.com> wrote: > > 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" > > > -- "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 -~----------~----~----~----~------~----~------~--~---
