This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: [CFP] Native XSLT in Smalltalk
Feed Title: Michael Lucas-Smith
Feed URL: http://www.michaellucassmith.com/site.atom
Feed Description: Smalltalk and my misinterpretations of life
Here's a call for participation. Are you interested in contributing some spare time here/there to work on an open source Smalltalk application that natively compiles XSLT in to Smalltalk, lets the templates be browsed as if they were normal methods, etc.. ?
If you are, then please reply to this blog post so that we can talk some more about it. I've made a start on it already and the concepts seem sound, so here's what I have so far:
First of all, XSLT is broken up in to two parts. Template matching and Template execution. The execution of a template will be compiled in to Smalltalk code which is naturally compiled down to bytecodes and jitted. The template matching is a runtime exercise and, while the code that does the match may also be compiled down in to Smalltalk code, it is in a slightly different camp.
I've added a Template class which can act as a method selector name. When figuring out which template to match upon, we simple ask each selector on the class we're running on if it matches the tag we're trying to match. If its a regular selector, we ignore it, if its a template selector, we ask it if it really matches. If it matches, we then send that template as a message send to the class doing the transform.
Sending a non-symbol as a message send works already. Having a non-symbol as a symbol in the methods dictionary works too. Basic compilating of a Templates execution in to Smalltalk also works, with the compile integrated in to the development environment.
What is missing is the runtime matching mechanism, the compiling of matches in to Smalltalk code, a complete set of compilation of the XSLT syntax in to Smalltalk code, variables and variable scopes, named templates with parameters that may get called by template execution, output formats on the resulting DOM tree, etc, etc...
And for the future.. if all this falls out nicely, I'd also like to try and use this system as an incremental XSLT transformer for partial DOM tree transforms. But that's for the future.
What do I hope to achieve out of all this?
Have fun
A native XSLT processor for VisualWorks (and any other Smalltalk that can hack the tricks)
... which should be fast as it will end up being jitted down in to native machine code
... which should be easy to debug, as it ends up as Smalltalk code in the end calling Smalltalk methods
A mechanism for providing a URL to the system and having it compile it up and record that URL against the new class its made
Do an XSLT processor in a way no one else has done! ;)
So, if you're interested, you know Smalltalk, you know VisualWorks, you know XSLT and you want to get involved, please let me know. I cannot do this entire project on my own.
Previous Topic
