Related
making XSLT readable - has this been done before?
Published 2007-04-11 13:46:00
We where discussing with one of my clients the idea of including dynamic content on their home page, which is currently static HTML, due to extreme load requirements. Normally Php is only reserved for specific parts of the site, and not on the front page.
I had the idea of using XmlHttpRequest, however another member of the team suggested XSLT, and I have to admit, I've never seen that idea before, and the example he showed basically included content from an external file by just adding a simple tag like
<our:include src="mydynamic.html" part="xxx" />
Where the mydynamic.html could use the 404 handler trick that php.net uses. (eg. if the file doesnt exist, it gets generated by the 404 handler, and deleted by a cronjob every 5 minutes etc.)
My only reservation about this is really that XSLT templates are unreadable garbage. Hence if we ever started to get clever with them, they could quickly become unmaintainable.
This however didnt seem to be a problem so much with XSLT but the fact that reading and writing XSLT files is not particulaly simple. Looking at the Basic specification for 1.0, and the example file he had, it seem clear that this file could easily be generated by a simple tool. However I could not find anything after a quick google search that seemed to exist to do this. So I threw together a simple proof of concept.
What if the template looked more like this:
Compile parser generator:
Convert the above file to xslt:
And magically you have a generated file, and a maintainable version.. - Makes me wonder though, has someone done this already?
the source: xsltgen.d
output from the above example: inctest.xslt
I had the idea of using XmlHttpRequest, however another member of the team suggested XSLT, and I have to admit, I've never seen that idea before, and the example he showed basically included content from an external file by just adding a simple tag like
<our:include src="mydynamic.html" part="xxx" />
Where the mydynamic.html could use the 404 handler trick that php.net uses. (eg. if the file doesnt exist, it gets generated by the 404 handler, and deleted by a cronjob every 5 minutes etc.)
My only reservation about this is really that XSLT templates are unreadable garbage. Hence if we ever started to get clever with them, they could quickly become unmaintainable.
This however didnt seem to be a problem so much with XSLT but the fact that reading and writing XSLT files is not particulaly simple. Looking at the Basic specification for 1.0, and the example file he had, it seem clear that this file could easily be generated by a simple tool. However I could not find anything after a quick google search that seemed to exist to do this. So I threw together a simple proof of concept.
What if the template looked more like this:
template("/") {
applyTemplates;
}
template("*") {
copy {
applyTemplates("@*|node()");
}
}
template("processing-instruction()") {
copy {
applyTemplates("@*|node()|text");
}
}
// make h1 green
template("html:h1")
{
copy {
attribute("style") <colour:green>
applyTemplates("@*|node()");
}
}
template("our:include")
{
variable("part", "@part");
applyTemplates("document(@src)//*[@id=$part]");
}
Writing a simple parser generator in D, enabled the generation of the xslt file from this file.Compile parser generator:
dmd xsltgen.d -of/tmp/xsltgen -od/tmp
Convert the above file to xslt:
/tmp/xsltgen inctest.xslts
And magically you have a generated file, and a maintainable version.. - Makes me wonder though, has someone done this already?
the source: xsltgen.d
output from the above example: inctest.xslt
Better than I expected but...
Interesting, but the proof is in more complex templates, not simple ones like this. I expect that if a template contained more literal markup, the regular XSLT syntax would be much more readable because in that syntax XML represents XML.
Your syntax is also missing namespace declarations as far as I can see, which makes it unsuitable for pretty much everything. That would have to be fixed.
Finally it depends on argument position (variable("part", "@part")) rather than explicitly named quantities. That makes it harder to read for these things.
Interesting, but the proof is in more complex templates, not simple ones like this. I expect that if a template contained more literal markup, the regular XSLT syntax would be much more readable because in that syntax XML represents XML.
Your syntax is also missing namespace declarations as far as I can see, which makes it unsuitable for pretty much everything. That would have to be fixed.
Finally it depends on argument position (variable("part", "@part")) rather than explicitly named quantities. That makes it harder to read for these things.
Sam willmot has done a presentation like that
http://www.idealliance.org/papers/extreme/proceedings/html/2006/Wilmott01/EML2006Wilmott01.html
http://www.idealliance.org/papers/extreme/proceedings/html/2006/Wilmott01/EML2006Wilmott01.html
Yes, someone did something similiar:JSLT
Take a look at:
http://www.rikarends.com/jslt-alternative-to-xslt
seems interesting, and the template-parser is written itself in JavaScript (I think :P)
regards,
Elias Baixas
Take a look at:
http://www.rikarends.com/jslt-alternative-to-xslt
seems interesting, and the template-parser is written itself in JavaScript (I think :P)
regards,
Elias Baixas
Yes, resin did sth similar
Resin (one of the servlet/jsp engines) did similar thing long long ago. But I'm not sure whether they still support it now (maybe this feature has been dropped).
Anyway, In my opinion, xslt is not suitable for complex page which may include javascript to manipulate the page contents.
Resin (one of the servlet/jsp engines) did similar thing long long ago. But I'm not sure whether they still support it now (maybe this feature has been dropped).
Anyway, In my opinion, xslt is not suitable for complex page which may include javascript to manipulate the page contents.
Add a comment (requires javascript!)

Comments