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

Reply via email to