Hi Venkatesh, The code is only available as part of GWT trunk; it's not a separately downloadable library. To get going with the trunk, take a look at:
http://code.google.com/webtoolkit/makinggwtbetter.html#workingoncode - Amir On Wed, Aug 12, 2009 at 2:27 PM, Venkatesh Babu <[email protected]>wrote: > > Hi All, > > Pardon me for my ignorance, but just wanted to know - Is the UiBinder > source code available for public review/use? If so, where can I get > the svn location or the URL to download the source code? Would really > appreciate if somebody throws light on this. > > Thank you, > Venkatesh > > > > On Aug 6, 11:32 am, Ray Ryan <[email protected]> wrote: > > Submitted at r5896 > > > > On Thu, Aug 6, 2009 at 7: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 -~----------~----~----~----~------~----~------~--~---
