<snip/> > My only concern is that it would make life harder for nontechie > designers. Then again, it might not - the XSL templates would rarely > need to change, and it would be easy to build up a "vocabulary" of xml > elements so that actual page content might look very simple. The > downside of this is that it completely abandons standard html editor > tools... which were probably choking on the velocity anyways.
Having been a cocoon user for a long time XSLT is something that the majority of developers will never "get". It's a big mind shift from an imperative to a functional language. So I would caution against exposing XSLT to the masses. On the other hand if the xml to X/HTML where hidden then I think most designers would be okay with it. Hell they can even preview with a <?stylesheet ?> a the top of the file. > A lot of my desire for this approach comes from using the Tigris CSS > stylesheets. CSS is supposed to separate style from content but the > HTML ends up looking pretty miserable anyways, with strange divs and > classes and all manner of incomprehensible junk. I'd rather specify tab > pages with real XML tags like <tabbed> instead of figuring out the right > CSS classes to put on table cells. Not all pages have to be a bloated with divs as the ones sampled in the Tigris CSS pages. I work on pure XHTML Strict and try and maintain as many of the WAI points as possible (a pain in the ass at first but it becomes second nature pretty quickly). One problem that I run into with css is that you can't re-arrange the node order. What I've been doing is pre-processing as part of my build. I run a series of XSLT transformations on the source files to produce the .vm files. No XSLT weight at runtime :). Just my two cents. -k. -- If you don't test then your code is only a collection of bugs which apparently behave like a working program. Website: http://blogs.codehaus.org/people/kevin/ Pub Key: http://blogs.codehaus.org/people/kevin/public.asc
signature.asc
Description: This is a digitally signed message part
