|Dynamically changing XML|
October 12, 2003, 5:44:41 pm
What does that mean? Well, if you specify that a document should be transformed, you will end up with the transformation result as the XML being used to render the output to the user.
In one example I'm building I have a list of <people> and each of those turns in to some div's and span's to XHTMLise it and add in some class's to give them style.
The real trick in all this is being able to go from all the div's and span's back to the person that it was generated from. I've recently added this 'back mapping' capability to VW's XSL processor.
But that wasn't enough. The XSL processor didn't use node builders like the rest of the XML processing code. I believe this was just a rush job on Cincom's part. Likely by the time Steve Dahl is finished with this baby it'll be able to run as a SAX processor or DOM processor :)
So now my version of the XSL processor uses node builders to generate XML.Element's and XML.Attribute's - this means the with:Style specialisation engine can work with it.
On top of this I've added some really simple ways to extend your original XML. With methods such as removeNode:, you can remove an existing node. replaceNode:with:, you can swap an existing node for your node.
So! We can get to the original XML and we can modify it. Well, it just so happens that if you do that in with:Style, the system takes note of it and does a 'rebuild'. It will transform its output XML to match what it should look like because of any XSL rules. Those who have played with Xopus will be familiar with this concept.
As with all things, it's never quite as simple as it sounds. This was no exception. I'm still trying to iron out the bugs. There are points in the system that cache too much information and they run in to problems when the original XML begins to change.
But given the kind of outputs I'm already getting, I extended the people example to have an 'add' and 'remove' link for each person. This example now /almost/ works.
Bigger picture time: Adding and Removing XML nodes from your original XML can be driven by rules from an XSchema. Those rules can be exposed to the user via relabelling in toolbars and popup menus. What you end up with is XSchema compliant XML (it can't not be, unless you use scripts to invent new tags on the fly) and alls that is left for an XML editor is the actual text editing and attribute editing bits.
So! This beast has come along way in the last few weeks and I'm going to submit this as my excuse for not blogging about it. I didn't want to start blowing the horn until I was sure the direction was valid.
Other features that will then be investigated are 'mass operations' such as drag+drop text around, images around, parts of document fragments, cut/copy/paste/delete.. We have it all scoped out now and it isn't -as- much work as you might expect. But it is still a fair slog.