This is a matter I too have raised before albeit in the context of Android, where sadly XML is pretty much mandated (unlike in GWT). I would imagine it's mostly due to an ambition of a UI builder, where Matisse/NetBeans have shown us that tools have a very hard time coming to grasp with a layout done through pure Java source code (no way to isolate this aspect, lots of locked lines etc.).
/Casper On Nov 23, 4:54 pm, Alexey Zinger <[email protected]> wrote: > 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? > > Alexeyhttp://azinger.blogspot.comhttp://bsheet.sourceforge.nethttp://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=.
