Xijiang,
Take a look at com.google.gwt.uibinder.sample.client.WidgetBasedUi &
WidgetBasedUi.ui.xml (part of gwt-user.jar). That test template uses
DisclosurePanel along with the other supported custom panel types.
- Amir
On Fri, Aug 21, 2009 at 7:13 PM, puttyshell <mia...@gmail.com> wrote:
>
> Ray,
>
> You mentioned that DisclosurePanel is supported by Uibinder. Do you
> know how to config the *.ui.xml?
>
> UiBinder greatly bridges the gap between traditional html design and
> the java coding. I am already very happy just using HTMLPanel + normal
> html + ui:field + styleName. :)
>
> ~Xijiang
>
>
> On Aug 6, 9:39 am, Andrés Testi <andres.a.te...@gmail.com> wrote:
> > UiBinder is awesome!
> >
> > An extra degree of decoupling, could be done by adding the next stuff
> > to the UiBinder interface:
> >
> > public interface UiBinder<U, O> {
> >
> > U createAndBindUi(O owner);
> >
> > public static interface Pair<U, O>{
> > R getRoot();
> > O getOwner();
> > }
> >
> > Pair<U, O> createAndBindUi();
> >
> > }
> >
> > where createAndBind() without parameters could instantiate an owner
> > class, enabling injection by constructor for UiField for more robust
> > code.
> >
> > - Andrés
> >
> > On 5 ago, 10:32, Ray Ryan <rj...@google.com> wrote:> 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
-~----------~----~----~----~------~----~------~--~---
