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 -~----------~----~----~----~------~----~------~--~---
