I didn't say it in the initial email, but Android was firmly in the back of my mind as I was writing it, as well as Java FX.
On Nov 23, 11:30 am, Casper Bang <[email protected]> wrote: > 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://wcolla... -- 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=.
