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 <[email protected]> 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 <[email protected]>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 <[email protected]> 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 <[email protected]> wrote: >>> >>>> I was thinking 2.1, actually. >>>> >>>> >>>> On Tue, Aug 4, 2009 at 12:31 PM, <[email protected]> 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 -~----------~----~----~----~------~----~------~--~---
