The first layer of the WAB relates to managing XML data in the context of an XML DOM. A fairly common use of this is for a node in one DOM to 'manage' another DOM, or at least provide a point of connection between one DOM and another.
Any node in the DOM can be a point of connection to this data, as indicated by the presence of the instance property.
A pointer to the DOM node referred to by an element's instance property can be obtained either directly on the connecting node, or via the document.instance function. The single parameter is an ID.
In mark-up, an instance element serves the purpose of a connecting node. There are two ways to use the instance:
- the entity can be specified inline as children of
instance; - the
instancecould be empty, indicating an uninitialised instance.
NOTE: The data will be flexible in the way that XSLT is. So all of these are valid:
<instance>hello, world!</instance>
<instance> <node>1</node> </instance>
<instance> <node>1</node> <node>2</node> <node>3</node> </instance>
Data islands good, but I really want MVC++
We want to process XML data, so we wrap an instance around it. Then we wrap a model around that. The model can contain lots of information about the data, like schema and business rules. These declaratively establish properties of the data and relationships among the data.
The real kick, though, is that we also have the latter two parts of an MVC. The view attaches to the model and allows two-way communication with the data for presentment and modification. Really, the modification part is an implicit/degenerate controller that supplies only a certain type of modifiability. And if you want more, there is this controller module that allows you to string together lots of inserts, deletes, and sets to achieve a specialized purpose.
The nice bit about this messaging is that MVC is a tried and true design pattern, so it's not like we're asking people to bet the farm on something that is risky or unknown. People get this.
But what's really interesting to me is that the VC parts are really just two specific cases of modules that can attach to a model to consume or update the data being managed by the module.
So, by MVC++ I mean that we have a model that any module can attach to in order to consume or update the data. Two other exciting modules that have come to our attention are submission and signatures.
Using event glue, these additional modules can meaningfully interact with the model. But, it also seems clear that even the view and controller modules could be written so that they interact with the model in exactly the same way, using events.
That's an implementation, of course, but the interaction between the model and the repeat module, the submission module, and the signature module can all be explained in the same way. This causes me to believe that events gives us a way of explaining how modules interact without having to invent custom plumbing for each new module that has to interact with the model.
Content model for instance
Right now, we allow an instance to contain a well-formed XML doc only, not arbitrary content.
In the arbitrary content case, there's no way to form an xpath data model over it to allow access to the data by other modules, like views and actions.
Are there real use cases for not insisting that the XML backplane is about processing XML data?
I think there is something to be said for being able to receive non-XML as the result of a submission, but to me this is really an argument to say that we need tighter control over where the submission result goes in the XML instance data, in which case we wouldn't have to insist on submissions returning XML.
Generating text files
The reason I suggested loosening things was that I didn't see any reason why we couldn't use XForms to produce a text file, for example. We can do that with XSLT.
Data island lifecycle and events
We've discussed on the telecon a few issues around the lifecycle of data islands...in particular: