Extras...

Are there any plans to build a ui tool (maybe in swing) so designers  
can drag n drop available widgets and have the view instantly updated?

Other kool features might include save the file etc.
Some of the extra features in interface builder.

Thoughts...?

On 26/08/2009, at 2:14 AM, Bruce Johnson <[email protected]> wrote:

> Hi Sony,
>
> I just wanted to clarify that UiBinder is based on XHTML not merely  
> to make coding more succinct vs. Java code. I agree that we could in  
> theory provide fluent APIs that could make Java imperative UI code  
> much more succinct than it is now. But there are three other big  
> motivations for UiBinder that wouldn't be address by fluent APIs  
> that I wanted to share.
>
> First, specifying layouts in XHTML encouages developers (by making  
> it easier) to use HTML rather than widgets/panels where the two are  
> effectively equivalent anyway. For example, it's just as easy to use  
> "<div>" instead of "<FlowPanel>" when you're already working in  
> XHTML, yet <div> is much, much better. Browsers can parse and render  
> HTML string fragments much faster than they can executing JavaScript  
> that builds DOM structures programmatically. So, really, UiBinder is  
> a trojan horse to get people to write apps that are smaller and run  
> faster :-)
>
> Secondly, many teams we've worked with at Google really like that  
> UiBinder creates a firm wall between the aesthetics of the UI vs.  
> its programatic behavior, which supports well the MVP pattern that  
> is becoming increasingly recognizes as The Right Way to architect  
> internet-based client/server apps. It's also a good way to divide  
> work in teams that have designers and developers; designers can mess  
> with the XHTML, developers can mess with the code and if they ever  
> diverge, you'll get a compile-time error. This seems to really  
> facilitate the kind of workflow in which a lot of people have  
> expressed interest since GWT 1.0. We're excited to finally be  
> getting there.
>
> Finally, GWT is all about finding coding patterns with which tools  
> (IDEs in particular) are useful. UiBinder's XHTML syntax makes it  
> easier to write good tools because it isn't as expressive as full- 
> blown code: more restrictive language means more ability to analyze  
> it statically, which is what tools are all about. Fluent APIs that  
> would encourage people to write UIs with Java code are less amenable  
> to creating good tools for them. For example, the Google Plugin is  
> already working on tools to make editing UiBinder templates easy  
> breezy, and we hope other IDEs will do the same.
>
> -- Bruce
>
> On Mon, Aug 17, 2009 at 11:32 AM, SonyMathew <[email protected]>  
> wrote:
>
> One point I have tried injecting into the GWT community is the
> importance of fluent APIs.  GWT's Java API is currently quite
> cumbersome for layouts and it seems folks immediately jumped to the
> conclusion that Java doesn't work and have gone the route of using XML
> for layouts.  I am not against folks that want XML layouts but there
> are many that feel fluent APIs in Java for layouts will be even more
> productive  Even if you layout your initial UI in XML you are still
> going to need to modify it dynamically in Java based on various events
> - so you end up having a eye sore mix.
>
> I put out an example of a fluent API called AxisPanel (search for it)
> - its not a great implementation - but it pretty much let me layout
> everything pretty quickly and changed the pace of my GWT development
> drastically - especially when it came to modifying layouts with new
> requirements.  Speaking for myself - I would like to see more such
> APIs (and better implementations than my AxisPanel) that folks can
> rely on as part of the Core GWT.
>
> I don't think developers starting a new GWT project would adopt XML
> layouts if they could fluently layout in Java right alongside the rest
> of their coding (at-least thats my theory)..
>
> Sony
>
> On Aug 10, 8:59 am, Arthur Kalmenson <[email protected]> wrote:
> > Hello everyone,
> >
> > We've been playing with UiBinder and I thought it'd be a good idea  
> to
> > share what we've seen so far (and ask some questions).
> >
> > Some of the apps we write are used by more then one hospital and  
> this
> > requires a tailored UI depending on the user's preferences and to
> > store additional information that a particular hospital needs to  
> keep
> > track of. At the moment, writing UI in a swing style, we program to
> > interfaces and use GIN to bind everything together. Using different
> > AbstractGinModules and Ginjectors, we can tie the application  
> together
> > in different ways using different UI implementations. What would be
> > the way to do this with UiBinder? From what we could tell, one would
> > use UiTemplate, but there doesn't seem to be a way to configure the
> > String in UiTemplate easily through a GIN module. Are there
> > alternatives?
> >
> > Following the programming to interfaces theme, we've been doing that
> > with UiBinder, but have run into an issue when trying to build a
> > larger UI page out of smaller ui.xml classes. It seems that  
> referring
> > to interfaces in ui.xml doesn't work, so you need to work with  
> direct
> > concrete classes. But this would force you to use a particular
> > implementation when we'd like to keep it generic.
> >
> > Lastly, I guess this is something just for consideration for the
> > future, but having the GEP work with UiBinder would make using it a
> > lot easier. For example, having code completion, refactoring support
> > and error messages right in Eclipse. This would be something like  
> the
> > Spring IDE plugin that one you configure Spring XML files with all  
> the
> > above features.
> >
> > Thanks again for the UiBinder, we'll definitely have to spend more  
> time with it.
> >
> > Best regards,
> > --
> > Arthur Kalmenson
>
>
>
> >

--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---

Reply via email to