Hi Bruce,
The goals you stated have been long sought by developers everywhere
(including me) and I hope you guys achieve it. In fact our last-gen
web tool/framework choice was based on this principle of roles
separation - but in all my years I have just never seen this work
(yet) - I am curious to know if your team or anyone has effectively
achieved this.
We finally rested on the following separation - allow UI designers to
use their favorite tool (e.g. Dreamweaver) to create full-fledged
mockups, then let the developers work off those to recreate the UI.
Attempting to share the underlying artifacts just lead to a lot
complexity especially with several cycles of modifications - and -
both sides had to settle for tools & syntax neither were comfortable
with. Now with GWT - the UI designers use their tools and syntax and
the developers use their IDE and Java.
Now within developers, further role separation occurs between the UI
coders and the Service coders and so on (perhaps this is the
separation you were referring to) - but this is transitional at best
(as they switch around) - we do this now - some work on Panels (views)
exclusively for a while and so on. Even here separation using XML
likely means the same last-gen dev style - such as expression bindings
to Java variables and pretty soon Loop / If-then-else (and other
language constructs) in your XML to accommodate the dynamic behavior
expected from a view. The UI developer is restricted by XML rather
than having the full flexibility of OO at their finger-tips.
Regarding tooling:
Java can be statically analyzed - an IDE is the best example of a tool
that can analyze it.
Regarding performance:
The GWT compiler analyzes Java for optimization now - you could
provide APIs like panel.freeze() to allow static pre-generation of
HTML of frozen Panels (just throwing out ideas - not thought out
yet)..
An example of using a Table with Java rich goodness using Fluent
APIs...
public class DrugPricePanel extends SimplePanel {
public DrugPricePanel() {
AxisTable table = new AxisTable()
//main header
.nextRow()
.place("DrugPrices: An AxisTable Demo:
buildRowByRowPlaceDirectDemo")
//drug & costs header
.nextRow()
.place("Drug Name") //place content directly
into cell.
.place("--")
.place("Specialty")
.place("90 Day Mail")
.place("90 Day Retail")
.place("30 Day Retail")
//drug info + total costs
.nextRow()
.y() //Nest an
AxisPanel as cell content
.x(widgets.drugName).q() //(see AxisPanel info -
layout in x or y axis).
.x(widgets.drugDesc1).q()
.x(widgets.drugDesc2).q()
.q()
.place("Total Costs")
.place(widgets.drugTotalCosts.specialtyCost)
.place(widgets.drugTotalCosts.ninetyDayMail)
.place(widgets.drugTotalCosts.ninetyDayRetail)
.place(widgets.drugTotalCosts.thirtyDayRetail)
//your costs
.nextRow()
.place("Your Costs")
.place(widgets.drugYourCosts.specialtyCost)
.place(widgets.drugYourCosts.ninetyDayMail)
.place(widgets.drugYourCosts.ninetyDayRetail)
.place(widgets.drugYourCosts.thirtyDayRetail)
//main header //span across all columns
.cell(0,0).span(1,7)
//drug header //span 2 columns
.cell(1,0).span(1,2)
//drug info //span 3 rows and 2 columns.
.cell(2,0).span(3,2)
;//end-table
this.setWidget(table);
}
class DrugCostWidgets {
Label specialtyCost = new Label();
Label ninetyDayMailCost = new Label();
Label ninetyDayRetailCost = new Label();
Label thirtyDayRetailCost = new Label();
}
class Widgets {
Label drugName = new Label();
Label drugDesc1 = new Label();
Label drugDesc2 = new Label();
DrugCostWidgets drugTotalCosts = new DrugCostWidgets();
DrugCostWidgets drugYourCosts = new DrugCostWidgets();
}
private Widgets widgets = new Widgets();
}//end-class
On Aug 25, 11:14 am, Bruce Johnson <br...@google.com> 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 <xsonymat...@gmail.com> 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 <arthur.k...@gmail.com> 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
-~----------~----~----~----~------~----~------~--~---
