XML has its roots in HTML, which has its roots in SGML, which comes from the publishing industry, where you have vast tracts of raw text with a very occasional tag in it. This explains almost all of XML's silly structure; the need to mention the tag name when you close one (useful, if most tag openers and matching closers are hundreds of lines apart, and arch formatting (where you indent each line according to their nesting level; they way we write java code, for example) is just not very feasible. Also explains to a lesser extent why you have both attributes and the concept of child nodes.
Unfortunately, somehow us programmers jumped all over this like it was sliced bread. Sometimes we're a bunch of idiots, really. XML fails precisely because that publishing model is not at all similar to config files, or, worse, 'programming'. Thus, ant build file writing and reading sucks *badly*, XSLT never really caught on much (at some point there was an actual CSS vs. XSLT war, can you imagine that?), even XHTML has trouble establishing much of a foothold (though that one doesn't really belong in this list; its reason for fail is mostly not directly the fault of XML). Writing up the structural bits of a GUI with XML is similarly silly. I have no idea why the GWT team went there. I have no idea why android did that. Something like F3, which is now better known as javafx script, is a way nicer 'language' to write this in. The fact that its an actual language, with the full power of one, is mostly a good thing. In a pinch, use JSON instead of XML for config formats. Something akin to javafx script, or maybe javascript, or possibly embedded python, is a better plan if you're 'programming' (think ant). Something like gant (ant, but build files with groovy), or gradle (like maven, but config written in groovy) so easily beats their origin counterparts primarily because XML is just such a pain to write and read back unless you're actually writing a book. On Nov 23, 5:37 pm, Alexey <[email protected]> wrote: > 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=.
