Loosely Coupled Objects and Declarative Programming

An interesting thread was started recently on the SVG Developers list by Peter Kalev. He said:

the web application we are building has really grown up and is beginning to tax the reach of JavaScript – by that I mean more then 12,000 lines of code … That is why we are looking to move to a more robust/rich programming environment.

This is exactly the type of issue that I'm keen to see debated, so I was pleased when a number of people responded. If you have the time, all of the threads are worth a read -- but I'll give a quick summary here, anyway.

Peter's problem is that he wants to use SVG, but he now has an enormous number of lines of script. Francis Hemsher replied saying that Peter's problem was really a matter of organisation since Francis himself was:

working on an SVG project with over 300,000 lines of code and still counting...Using Javascript within the IE5.5/6 browser.

In his view:

If you have a solid Object-based project, then javascript can do it all.

Jan-Klaas Kollhof also felt that sound OO practices would solve the problem:

How is 12,000 lines a problem?

I am not sure how many lines of script Mozilla has but the number is not small.

The only problem I can think of is managability and maintanence of code and intensive calculations that just take too long in JS.

Now, for the latter there is not much you can do besides optimizing your code or get a more performant JS impl.

For managing your code use clean modularization(packages, ...) so you don't get nameing conflicts, can write module test routines, ... But that concept you would apply anyways even using another language. Call it packages or whatever. OOP consepts you can apply as well.

Kurt Cagle also commented, and said that it should be possible to reduce the script level by using a higher-level language to drive the SVG:

... you may also want to look at C# SVG implementations, such as that produced by Mobiform or Don Demsiak's (Don XML's) Sharp Vector Graphics implementations. They both use C# as their central binding languages, and both can be run from within a browser.

Whilst I would never say that you shouldn't use 'sound OO techniques', my own comments centred around using a declarative approach, rather than scripting. I suggested that the place for SVG was in the widgets, not controlling the actual logic of the application, which means that:

[...] we get a genuinely clean separation; the SVG code deals only with how the thermometer looks and perhaps acts (the user may be allowed to slide the indicator, for example). And XForms looks after the data, submission, schema types, validation, calculations, and so on. XForms tells the SVG widget when the data has changed, or has become invalid, and the SVG widget tells XForms if the user has entered a new value. But the SVG widget could now be used in an numerous different places, on many different forms, whilst equally, the underlying form could be used with a range of different widgets, for different environments.

One interesting issue that often comes up when discussing declarative programming is whether it really differs from procedural programming at all. As the discussion continued I tried to explain the difference between OO programming and using declarative mark-up; I described a simple XForms control:

I think this is where we get to the nub of it; is it just a case of using modules and objects? My suggestion was to use declarative mark-up like XForms which decreases maintenance and increases development speeds by an order of magnitude, way past OO techniques. For example, the following mark-up in XForms does an incredible amount of work:

  <xf:input ref="name">

    <xf:label>Name:</xf:label>

    <xf:hint>Enter your name here</xf:hint>

    <xf:help>This is where you would enter your name</xf:help>

    <xf:alert>You must enter your name</xf:alert>

  </xf:input>

First, it specifies where the value that the user enters should be stored -- in this case in an element called 'name', in the default instance DOM.

Next it says that there is a label for the control, as well as a hint. In a visual system the hint will probably be rendered when the user mouses over the control, but it could be triggered by the user pausing for more than a certain amount of time on the control, etc.

The help text would be rendered to the user on receipt of a request for help, which on Windows is pressing [F1], but again it could be something else.

And finally, the alert message is rendered to the user whenever the data entered goes invalid. The conditions for validity are not defined here, but they might be that the text is not empty and less than 200 characters, or whatever.

However, Jan-Klaas replied:

[...] in script the above decl. would be
inp = new Input("name");
inp.label = "Name:"
inp.hint = "..."
...

There are many reasons why this is not a correct mapping, and I won't go into them all here. But the single biggest difference between this and the declarative approach I've been describing is not actually the fact that it is procedural, but the way that objects are used.

What Jan-Klaas has done is to create an input object, and this input object has two properties, a label and a hint. This is of course a common approach to OO, in that the object contains and knows about its features.

However, I wasn't saying that mark-up like this:

  <xf:input ref="name">

    <xf:label>Name:</xf:label>

    <xf:hint>Enter your name here</xf:hint>

    <xf:help>This is where you would enter your name</xf:help>

    <xf:alert>You must enter your name</xf:alert>

  </xf:input>

meant that the input has a hint property. I am actually saying that there is a hint object that is related to the input object, but that the input object knows nothing about it (and vice versa). The hint object does all the work to support 'hintness' and the input object does all the work to support 'inputness'. The hint object may wire itself into the mouseover events on the input, but still the input object is none the wiser that it now appears to have the ability to behave 'hintily'.

Why is this important? Well, it firstly makes applications much easier to design, build, and test. Secondly, it conforms more closely to the trendy notion of pattern programming -- in this case we could say that the hint is a pattern in which some UI event causes some message to rendered and then some other event causes that message to be removed.

But thirdly -- which is where I feel it gets really interesting -- it makes it easy to 're-skin' these objects; if I want to have an SVG rendered input control, but with voice rendered hints, I can do it in this model.

I'll discuss this architecture in more detail once we've finally (don't ask) got formsPlayer version 2 into the public domain. In the meantime, if you are interested in an overview of this and related concepts (particularly the idea of using patterns for this type of work) you can read a paper that I submitted for the W3C Workshop on Web Applications and Compound Documents. (My presentation is minuted here.)