Erik Hollensbe wrote:
I imagine that many of your applications can either be tailored to, or already produce sane XHTML output. I'm also getting the feeling that several of your applications are third-party, which limits what you can do with them (either from a time or possibility perspective). So, in the case where you have no choice, slap a hpricot-based filter on them, and generate predictable XHTML. Then, XSLT can be used on all the applications to produce a template which your content editors can use - if designed properly, this will make it easy (as possible) for them to change the interface on a whim (which was the case at all the places I have worked at previously). You could even write an interface to help them manage the individual transformations required, if necessary.
I like this suggestion.
The SiteMesh best-practices recommend that you rewrite the underlying pages to simplify the transformation, but that won't work if there are third-party apps involved whose code is out of reach or too troublesome to edit. The two stage transformation process you described is actually what I meant by, "your colleagues probably won't be able to work with this code directly, so you'll have to hide it behind a friendlier template", but you did a better job explaining and also provided a good implementation suggestion.
Both of these stages could also be performed using an XSLT-to-XSLT pipeline transformation. However, sanitizing pages with something like Ruby's Hpricot or Python's BeautifulSoup would be much easier than with XPath. These parsers might just be fast enough to do the job, and even if they're not, it would still probably be quicker to first prototype with them before writing an optimized version in XSL.
-igal _______________________________________________ PDXRuby mailing list [email protected] IRC: #pdx.rb on irc.freenode.net http://lists.pdxruby.org/mailman/listinfo/pdxruby
