TreeBind, Data binding and Design Patterns

I have released a new version of my Java data binding framework, TreeBind and I feel I need to explain why I am so excited by this API and by other lightweight binding APIs…

To make it short, to me these APIs are the latest episode of a complete paradigm shift in the relation between code and data.

This relationship has always been ambiguous because we are searching a balance between conflicting considerations:

• We’d like to keep data separated because history has told us that legacy data is more important than programs and that data needs to survive during several program generations.
• On the other hand, object orientation is about mixing programs and data.

The Strategy Pattern is about favouring composition over inheritance: basically, you create classes for behaviours and these behaviours become object properties.

This design pattern becomes still more powerful when you use a data binding API such as TreeBind since you gain the ability to directly express the behaviours as XML or RDF.

I have used this ability recently in at least two occasions.

The first one is in RDF, to implement the RDF/XML Query By Example language that I have presented at Extreme Markup Languages this summer.

RDF resources in a query such as:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns="http://xml.insee.intra/schema/annuaire/"
  xmlns:q="http://xml.insee.intra/schema/qbe/">
    <q:select>
        <q:where>
            <inseePerson>
                <mail>
                    <q:conditions>
                        <q:ends-with>@insee.fr</q:ends-with>
                    </q:conditions>
                </mail>
            </inseePerson>
        </q:where>
    </q:select>
</rdf:RDF>

Are binded into Java classes (in this case, a class « Select », a generic class for other resources for « InseePerson » and a class « Conditions ») and these classes can be considered as behaviours.

The second project in which I have been using this ability is for a list manager which I am writing to run my mailing lists.

This list manager is designed as a set of behaviours to apply on incoming messages.

Instead of providing a set of rigid parameters to define the list configuration, I have decided to expose the behaviours themselves though TreeBind.

The result is incredibly flexible:

<?xml version="1.0" encoding="UTF-8"?>
<listManager>
    <server>localhost</server>
    <storeType>imap</storeType>
    <user>listmanager</user>
    <password>azerty</password>
    <port>143</port>
    <folderManager>
        <folder>user.list</folder>
        <messageHandler>
             <ifIsRecipient>list@example.com</ifIsRecipient>
              <messageHandler>
                <ifSpamLevelIs>spam</ifSpamLevelIs>
                <moveTo>moderated.spam</moveTo>
            </messageHandler>
            <messageHandler>
                <ifSpamLevelIs>unsure</ifSpamLevelIs>
                <moveTo>moderated.unsure</moveTo>
            </messageHandler>
            <sendToList>
                <subjectPrefix>[the XML Guild]</subjectPrefix>
                <footer>
--
Yet another mailing list manager!
></footer>
                <recipient>vdv@dyomedea.com</recipient>
                <envelopeFrom>list-bounce@example.com</envelopeFrom>
                <header name="Precedence">List</header>
                <header name="List-Id">&lt;list.example.com></header>
                <header name="List-Post">&lt;mailto:list@example.com></header>
                <server>localhost</server>
                <user>listmanager</user>
                <archive>archive</archive>
            </sendToList>
            <moveTo>done</moveTo>
        </messageHandler>
        <messageHandler>
             <moveTo>unparsed</moveTo>
        </messageHandler>
      </folderManager>
</listManager>

The whole behaviour of the list manager is exposed in this XML document and the Java classes corresponding to each element are no more than the code that implements this behaviour.

Unless you prefer to see it the other way round and consider that the XML document is the extraction of the data from their classes…