The GWT standard widgets already have custom parsers built for them. DockPanel, DisclosurePanel, Menubar, etc. all work just fine despite their wonky api needs. The bug here is that you can't indulge in similar glue for your custom widgets yet. No Google team has found that to be a problem with their custom widgets, which is I why I felt like I could get away with ducking that issue a bit longer.
On Wed, Aug 5, 2009 at 1:31 AM, brett.wooldridge <brett.wooldri...@gmail.com > wrote: > > Just a question, and a comment. First the comment. Thank you for > getting this up into the repo, in whatever state. Second, it was > commented that Adwords and a few other projects have vetted this over > the past year. How does this jibe with the deficiencies outlined? > For example, not being able to markup for DockPanel, etc? Did those > projects just have to go "off-roading" and create custom parsers based > on an API they knew they would eventually have to fix/rewrite? > > -Brett > > > On Aug 5, 5:49 am, Ray Ryan <rj...@google.com> wrote: > > I share your concern, Amir, but I'm even more afraid of a) providing an > ill > > considered API for custom parsers and b) delaying 2.0. I'm pretty > confident > > we can limp along without them for a dot release. > > > > > > > > On Tue, Aug 4, 2009 at 1:36 PM, Amir Kashani <amirkash...@gmail.com> > wrote: > > > As Ray mentioned, one has a pretty simple workaround and two is pretty > > > uncommon. I'm a little more concerned about the third case. A few > examples > > > of issue with internally used widgets I've created: > > > > > - A StackPanel replacement that adds animation support. The only > workaround > > > I can think of is having the add() method take a StackPanelItem or > similar > > > that contains the header text or widget. > > > - TitledPanel, which supports a header, content and footer area. In > this > > > case, the widget could expect several calls to add, and determine the > > > context based on number of previous calls. This would get a bit hairy > if > > > headers and footers were optional, though. > > > > > These scenarios are a bit inconvenient without a custom parser, but far > > > from a deal breaker. The concern is that people develop a set of > hackish > > > workarounds that aren't easily fixed when custom parsers are supported. > > > > > - Amir > > > > > On Tue, Aug 4, 2009 at 12:47 PM, Joel Webber <j...@google.com> wrote: > > > > >> There are three cases where custom parsers come up:1. Widgets without > a > > >> default constructor. > > >> 2. Non-widget UIObjects that need an XML representation. > > >> 3. Panels that need more than the default add() method to deal > properly > > >> with child widgets. > > > > >> The former is usually pretty easy to work around, and it seldom comes > up > > >> much in practice (I think it came up for MenuBar, because it wants its > > >> 'direction' as an invariant -- that wasn't even a good design anyway). > > > > >> The second case doesn't come up all that often, but it's important for > > >> menus and trees. > > > > >> The third case is the most problematic. Take DockPanel, for example: > It's > > >> really not going to be able to do anything useful if you just call > add() on > > >> it, because it doesn't know where to put the child. These sorts of > panels > > >> need extra attributes or elements to specify where to put children. > > > > >> On Tue, Aug 4, 2009 at 3:42 PM, Amir Kashani <amirkash...@gmail.com > >wrote: > > > > >>> What are the limitations for a Widget developer without a custom > parser? > > >>> I've only begun to look at the code, but it seems like it'll still be > > >>> possible to use a custom widget albeit with cumbersome markup. > > >>> - Amir > > > > >>> On Tue, Aug 4, 2009 at 12:35 PM, Joel Webber <j...@google.com> > wrote: > > > > >>>> Ok, then we'll need to be pretty clear about that in the > documentation, > > >>>> because it's a pretty serious landmine (i.e., in that existing > projects > > >>>> could easily have some widgets that couldn't be directly used with > UiBinder > > >>>> without hackery). As an example, I'm going to have to add some > parsers for > > >>>> LayoutPanel, et al, because they have somewhat unusual construction > > >>>> semantics. > > > > >>>> On Tue, Aug 4, 2009 at 3:31 PM, Ray Ryan <rj...@google.com> wrote: > > > > >>>>> I was thinking 2.1, actually. > > > > >>>>> On Tue, Aug 4, 2009 at 12:31 PM, <j...@google.com> wrote: > > > > >>>>>> On 2009/08/04 18:50:55, Ray Ryan wrote: > > > > >>>>>>> On 2009/08/04 17:44:38, Ray Ryan wrote: > > > > >>>>>> A question for the group: the stuff under rebind and parsers > should > > > > >>>>>> not be > > > > >>>>>>> considered public API, it's just not ready for that. Is javadoc > to > > > > >>>>>> that effect > > > > >>>>>>> enough of a deterrent? (Although I suppose the fact that you > can't > > > > >>>>>> actually make > > > > >>>>>>> your own parsers and such *do* anything yet will make the issue > > >>>>>>> moot.) > > > > >>>>>> I would assume that if you can't usefully write your own yet, then > > >>>>>> it's > > >>>>>> pretty safe to keep evolving the API. I assume that there's a > > >>>>>> 2.0-time-frame task to make a public API for parsers? > > > > >>>>>>http://gwt-code-reviews.appspot.com/51831 > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
