Yes. That's what I did. Thanks! I have to enable the animation to use two nested DisclosurePanel. Otherwise, the parent disclosure panel does not resize properly when the child panel is opening/closing.
On Sun, Aug 23, 2009 at 1:57 PM, Amir Kashani <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 < >> [email protected] >> > >> > > > 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 <[email protected]> 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 < >> [email protected]> >> > > > 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 <[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 -~----------~----~----~----~------~----~------~--~---
