JavaOne is coming up, and with it no doubt a slew of enhancements to JavaFX. Many of you reading will have no doubt dipped your toe into the waters of Sun's new platform, but how well do you really understand the power of its Domain-specific language, JavaFX Script?

I've had a pretty good excuse to write lots of JavaFX code of late, and to be exposed to some of the difficulties programmers first have when approaching the language. One of the common stumbling blocks seems to involve the shift in thinking from purely procedural source code (where the function/method is our chief currency) to the declarative source code supported by JavaFX Script (where code may be nested into a tree structure).

So, what I'm going to do in this post is take a problem ripe for declarative exploitation, and show how JavaFX Script might change the way we tackle the solution. For newbies struggling to understand the power of JavaFX, hopefully this will be an eye opener. For the uninitiated, perhaps it might demonstrate how JavaFX Script differs from Java and other languages.

The example I've chosen is the parsing of an XML file — a simple enough task one might think, but a task which highlights the stark contrasts between the structure of the document being processed, and the structure of the source code processing it. (Hopefully that last sentence will make a bit more sense by the time you've finished reading this posting!)

To parse XML in JavaFX we would typically reach for the javafx.data.pull.PullParser class. PullParser walks the document from start to finish, breaking the XML up into a stream of events: for opening tags, for closing tags, and for any loose text inside them. We register a function to receive the events as they come in, and do with them as is our wont. It all seems very straight forward, so where's the problem?

Consider the (slightly contrived) XML below:

<?xml version="1.0" ?>
<shop>
    <version>1</version>
    <title>Shop example</title>
    <customers>
        <customer>
            <name>Joe Smith</name>
            <address>123 Java Street</address>
        </customer>
        <customer>
            <name>Fred Bloggs</name>
            <address>456 Duke Road</address>
        </customer>
    </customers>
    <products>
        <product>
            <name>Widget Maker</name>
            <price>20 groats</price>
        </product>
        <product>
            <name>Chocolate Fireguard</name>
            <price>99 credits</price>
        </product>
    </products>
</shop>

Both <customer> and <product> contain <name> elements, and both <name> elements are at the same level in the document. JavaFX's PullParser tells us about the element causing the event, but little of where the element is in the document as a whole (aside from its level). This results in long blocks of conditional code, along the lines of...

If the event is a 'text' event, and our immediate parent is <name>, and it was at level 3 in the document, and its parent was <customer>...

A bit of a mouthful, just to ensure we know which bit of text in the XML we're processing. And remember, the only way of knowing the lineage of an event is to keep track of where we are in the document ourselves.

Things get even messier when we want to populate objects as we process the XML. Suppose we created a couple of classes, one to hold customer details, the other to hold product details, and we intend to populate and store objects of these classes as we walk over the XML.

class Customer {
    var name:String;
    var address:String;
}
class Product {
    var name:String;
    var price:String;
}

var title:String;
var customers:Customer[];
var products:Product[];

Because each XML element is delivered as separate, discrete, events we can't use a local Customer/Product object; any objects we create must persist over multiple event function calls, giving us little alternative but to use private instance variables for this temporary data.

For any non-trivial XML document the event handling code quickly grows in complexity and acquires a burgeoning collection of private variables for maintaining state. The code starts to become a tad spaghetti-like, and inflexible — even a simple change to the XML format may require a lot of code hacking. The problem is, of course, we're trying to apply a very linear way of working to a non-linear data structure. If only we could write our event handling code as a tree, so it would mirror the XML.

Expert JavaFX Script programmers will be able to guess what's coming next.

def shopEventTree = Element {
    name: "shop"
    content: [
        Element {
            name: "title"
            onText: function(ev:Event) { title=ev.text; }
        } ,
        Element {
            name: "customers"
            content: [
                Element {
                    name: "customer"
                    var c:Customer;
                    onStart: function(ev:Event) { c=Customer{}; }
                    content: [
                        Element {
                            name: "name"
                            onText: function(ev:Event) { c.name=ev.text; }
                        } ,
                        Element {
                            name: "address"
                            onText: function(ev:Event) { c.address=ev.text; }
                        }
                    ]
                    onEnd: function(ev:Event) { insert c into customers; }
                }
            ]
        } ,
        Element {
            name: "products"
            content: [
                Element {
                    name: "product"
                    var p:Product;
                    onStart: function(ev:Event) { p=Product{}; }
                    content: [
                        Element {
                            name: "name"
                            onText: function(ev:Event) { p.name=ev.text; }
                        } ,
                        Element {
                            name: "price"
                            onText: function(ev:Event) { p.price=ev.text; }
                        }
                    ]
                    onEnd: function(ev:Event) { insert p into products; }
                }
            ]
        }
    ]
}

Element is the first of two JavaFX classes designed to solve our problems. You can see it in action above, being used to create a tree which mimics the XML document we're loading. Each Element relates to a markup node in the document, with name representing the node's tag name. Three event functions (onStart(), onText() and onEnd()) fire on the opening and closing tags, or any loose text inside.

Note how we now handle the creation of those Customer and Product objects (see the highlighted text in the listing). The object is local to the part of the structure it belongs to: onStart() creates it, the corresponding onEnd() stuffs it into the sequence, and in-between the nested Elements populate it.

def xeh:XMLEventHandler = XMLEventHandler {
    eventTree: shopEventTree;
}
def parser = PullParser {
    documentType: PullParser.XML;
    input: (new java.net.URL("{__DIR__}test.xml")).openStream();
    onEvent: xeh.handleEvent;
}
parser.parse();
parser.input.close();

The Element class has a companion, XMLEventHandler, which accepts the Element tree and provides a function for PullParser to call with its events. XMLEventHandler tracks the XML's progress and directs the flat PullParser event to the related Element event function in our event tree. XMLEventHandler can tell the difference between the <name> in <customer> and the <name> in <product>, so we no longer need to worry!

The above is only an example, and far from perfect. For large XML documents the Element tree grows to hundreds of lines — hardly ideal. A more professional solution might demand the breaking down of the XML into several sub-trees, which we could model independently and re-use as necessary. Still, Element and XMLEventHandler serve their purpose as a demonstration of the power of thinking declaratively.

The beauty of JavaFX Script lies in its ability to shape code around the data structures we work with. By utilising JavaFX Script's declarative syntax we were able to transform a (potentially troublesome) linear event handler into an event tree who's source code mirrored the document being parsed. The result was more readable, flexible, and easier to maintain. So, bottom line: don't just think about code to manipulate your data, start thinking about code which mimics (models) your data... :)

[Source code] (3k)