You know the dream: write a configuration file, push a button and voila: a beautiful software application is born. Your work as developer is reduced to just those bits that make your system different from the rest, and all the monotonous bits are automatically generated for you. It’s a wonderful dream, but is it realistic? Does it really work? Read on for my experiences on this topic.
In my current project I have the privilege of working on a code generation framework. Our code generation framework uses a custom-built core engine that essentially marshalls an Object Model XML file into a Java Object and allows “Visitor Classes” to “visit” the Object Model Java Object to produce code artifacts (using the Visitor pattern). The actual production of code occurs by applying XSL templates to XML that is a subset of the great Object Model XML file. XSL templates can be designed and developed to produce most any kind of artifact.
The beauty of this approach is that with the Object Model XML schema and core engine in place, all that is required to produce some artifact is a custom visitor class for the type of code you are creating, an XSL template for producing the code, and registering your visitor class with the core engine. The result is an extensibility that gives us the freedom to produce all sorts of artifacts with not a whole lot of effort. And truly, to this day, we are producing Java beans (interface/implementation), Java bean wrappers, DAOs (interfaces, default implementations in straight JDBC and using Spring/Hibernate), XML schema for the object model, XML support classes (for serializing and marshalling model data), Database schema and more! Eventually we will also produce the basics for CRUD access via an MVC-based web application (JSPs, servlets, and configuration files). The promise is great. And so far, it is pretty impressive to see the amount of code that is already getting auto generated, and we aren’t done yet.
Sounds awesome so far, doesn’t it? Like most things in life, it’s not all pretty. XSL, while a powerful language in its own right for querying XML and producing XML and text data, is far from elegant, and in some cases down right atrocious. As I look at an XSL template that someone else wrote, and try and discern what is going on, I can’t help but think to myself, “I am expending more effort than I feel I should be.” It’s definitely not as nice as reading Java code, where methods, variables and such are easily read and followed. I remember Bruce Tate at one of our corporate events late last year saying he hated the angle brackets in XML. The more I stare at XSL templates, the more I am understanding his sentiment. And then of course there is the matter of how slow it is to produce truly useful, reusable code generation software. You have to constantly think abstractly, think about every possible specialization, and backtrack and refactor often. As a result it has taken us much longer to get to this point than had we just written the web application we were tasked to write directly, without a big, thick code generation layer of indirection.
My thoughts on the matter are as follows. Code generation is a great idea, a great approach. Imagine never having to write another Java bean? It’s a great prospect. To get over the XSL dilemma, I would suggest to try a different template language. Tea, Velocity — even JSP/JSTL is better than XSL for this purpose in my opinion. As far as how long it is taken us to get this far? I am OK with it. I mean, when we are done we will have a code generation framework in our hands that will truly be reusable for years to come.
We aren’t done yet! We are scheduled to be finished with a rough first cut of this framework this Spring. I’ll write an update then on how far we’ve progressed then.
Comments
I'm doing an application which generates a form from a XSD and produces the XML Document after the user imput the data inmto the form.
Please, if any one can help me in how to create an XML document from arbitrary data input by the user.
Regards
In my opinion, only advantage XML has over any other format is that it is agreed upon, for the most part; hence, the availability of some very useful tools.
Its transparency is only really useful if you are inclined to hand-jam the smaller XML files with a straight text editor. XML-Spy is popular because a tool is required to reliably manipulate more complex XML files.
I consider the hierarchical nature of XML more of a limitation than an advantage. Essentially a hierarchy is less powerful representation than a graph, which happens to be less powerful than binary relations used by mathematicians. By this I mean the successor can do
everything the predecessor can, and more.
That said, I do enjoy the benefits of code generation, where they make sense, and I do use XML when I need a tool that requires XML input.
I don't think you are necessarily limited to hierarchical
structures. In XML, there are the ID and IDREF attribute types to
reference entities outside the hierarchy.
For example, a Spring configuration file is essentially a graph:
You could make the argument that in this example "node1" is a child
of "node2" and "node3", but we could have created a "Tuple" element
that would relate nodes without a notion of ownership (and a "Graph"
element, which would collect of Tuples to be thorough).
On another note; I do dislike the attempts to force "programming" logic into XML, which is what XSLT does to some extent.
I generally find implementations of "scriptable"
XML to be incomprehensible.
I agree that XML is harder to read than Java code, but I wanted to
share with you and your readers my believe that XML is ultimately the
most flexible (and coincidentally, desirable) file format for
representing source code.
Source code files are much more than a collection of structured
statements and variable declarations. They also contains textual
descriptions of algorithms, copyright and licensing information, a list
of authors names and contact information, as well as important
meta-information about each method, expected usage, and so forth.
Sun recognized the value of this meta-information from the
beginning, and show great foresight by providing a standardized way of
encoding it into source files (i.e. with Javadocs).
With the release of Java 5, they went even further by extending the
Java language to support “annotations”. A full discussion of
annotations and their merits is beyond the scope of my response, but
nevertheless I think its demonstrates the importance of
meta-information in source code.
So what does all of this have to do with XML?
XML is relevant because it’s emphasizes TRANSPARENT access over
everything else; size, speed and efficiency be damned. It can be
compared to democracy which is inherently inefficient but the lesser of
all evils.
Transparent access should be important to all programmers, because
source code is the fruit of our labor. I love the idea of being able to
transform it, analyze it, study it, or improve it, using tools that may
not even exist today, because access to my source, in a structured
manner, is so easy.
Anyone who has ever tried to write a C or C++ language parser, knows
exactly what I am talking about when it comes to transparent access to
source code. Try writing a “syntax highlighter” or a “source code
beautifier” for C code (see GNU indent). It’s a freaking nightmare.
If C code was represented in XML, you could write XSL stylesheets to
transform it into Java in a fairly straightforward manner. Of course,
you’ll need to map C library calls to equivalent Java methods, but even
that could be automated if the source code was in XML… again, because
access to the source code is transparent.
Ultimately, the best way to make XML more readable, is for us to develop better viewers for XML.
Post new comment