I just happened to be looking at the GWT Wikipidea page and noticed a paragraph
describing some features for GWT 2.0, one of which mentioned XML UI definitions
in place of code. Being neck-deep in one of my GWT projects at work, this made
me wonder about the real utility of this approach when it comes to Java.
In the course of working with GWT, I quickly realized that building an initial
UI -- occasionally fairly complex right out of the gate -- was quickly becoming
design pattern that was begging for someflexible, easy-to-use API. So I wrote
some, greatly leveraging generics:
public static <T extends Panel> T populatePanel(T panel, Widget... widgets)
public static <G extends Grid> G populateGrid(G grid, Widget[][] widgets)
What does this give me? Well, it gives me fairly clean user code, a la:
this.initWidget(Util.populatePanel(
css(new VerticalPanel(), "panel"),
Util.populateGrid(
new Grid(),
new Widget[][]
{
{
css(new InlineLabel("Jurisdiction:"),
"jurisdictionLabel"),
css(this.jurisdictionEditor, "jurisdictionEditor")
},
{
css(new InlineLabel("Account Num:"), "accountNumLabel"),
css(this.accountNumInput, "accountNumInput")
},
{
css(this.firstCostLabel, "firstCostlabel"),
css(this.firstCostInput, "firstCostInput")
}
}
),
Util.populatePanel(
css(new HorizontalPanel(), "panel4"),
css(new InlineLabel("Authority Type:"), "authorityLabel"),
css(this.authJurisdictionRadio, "authority",
"authJurisdictionRadio"),
css(this.authThirdPartyRadio, "authority",
"authThirdPartyRadio")
),
grid,
));
It's not too hard to figure out the structure of this and what's going on, even
not being familiar with GWT API. Much can still be done to reduce verbosity
too. It has clear bindings to the local variables when needed. Compiler
provides a heck of a lot of static checking. I can easily abstract this away
into a separate source file if I wanted more MVC-like style.
So now my question is this: what do I get from XML UI definition that I'm not
getting from this now? I can see a few possible answers:
1. Non-coders would have an easier time authoring XML from some tool and coders
and non-coders can collaborate on GUI creation.
This is an old argument, often employed to defend complex GUI engines (Java FX
Photoshop integration anyone?) and I'm just not buying it. Granted, I haven't
spent enough time in client-side Java shops (who has, these days?), but so far
in my experience, I see people exchanging all kinds of garbage in mock-up
stage, until they get to the part where it needs to be put in a working
application and someone ends up coding it from scratch, using the mock-up files
for reference. I've never seen anyone take a mock-up file and somehow actually
be able to plug it into the code. Moreover, when I did work for a few
client-side Java shops, where we were coming up with all manners of clever
things, this idea wasn't even on the radar as something we might want to build
for ourselves.
2. XML can be coming from some place dynamically and it would make it real easy
to display a totally custom UI on the fly that way
I can see this being relevant in an environment, where it would be difficult to
leverage existing libraries to build that behavior or dynamically created HTML
on the server. Neither is the case for GWT. We can embed HTML pages, redirect
a user to a link, or write a simple GUI loader that works with GWT's standard
RPC or some custom whachamajigger, such as an XML format, if we really need it.
Once again, I'm not seeing a big benefit here.
3. XML is designed to be good at structure definitions, Java source is not
This may be a matter of taste, but in terms of readibility, my own
not-very-well-thought-out API give me client source code that is indeed fairly
readable and shows the structure quite well. Since then, I've adopted this
pattern in some of my own Swing projects as well. Generics gave us enough to
work with on top of good old Java to express these concepts well in source.
And when it comes to dynamic GUI building, as was touched on in the previous
point, then, we can use some RPC protocol that may or may not use XML, but at
that point it's just an implementation detail. But what would count is that
we'd be marshalling real Java objects (as our source code is concerned) giving
us all the structure and type safety we might want.
Mind you, I can see how XML GUI definitions can be really nice in some
languages and environments. It just feels like it's also becoming a bit trendy
and is permeating more projects as a core feature than it really needs. Or am
I missing something?
Alexey
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=.
