This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Dynamically changing XML
Feed Title: Michael Lucas-Smith
Feed URL: http://www.michaellucassmith.com/site.atom
Feed Description: Smalltalk and my misinterpretations of life
Recently I've been focusing my efforts in with:Style to making the system really flexible and scriptable. We now have both Smalltalk and Javascript scripting abilities for it and we also now have XSL firmly rooted in to the 'core concepts'.
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.
But the real killer addition is addXMLString:, which will parse the string as a document fragment and add that to the tree. Those who are familiar with Javascript will be saying "So what?" - well, exactly. These features are heading us towards being able to do what DHTML and Javascript can do.
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.
Previous Topic
