Stefano Mazzocchi <[EMAIL PROTECTED]> <snip/>
> if the sitemap is the ultimate pipeline engine and the > flow is the > ultimate (and transparently statefull!) controller engine, > what is the > *ultimate* view, the best template system? > > There are a bunch of paradigms on the table but they can be > separated in > two big groups. > > 1) generation based > 2) transformation based > > > both can be divided further into > > a) compilation based > b) interpretation based Would perhaps "functional" and "procedural" another useful way to slice and dice this? > The chart should be four-dimensional as we could add another two axis > based on the fact that we can further divide them into > > i) event stream based > ii) octet stream based > > and > > I) markup-based syntax > II) text-based syntax > > so, the final synopsis is > > XSP -> generation compilation event xml > JSP -> generation compilation octet xml(1) > Velocity -> generation interpretation octet text > X:Forge -> generation interpretation event xml > XSLTC -> trasnformation compilation event xml > XSLT -> transformation interpretation event xml > JXPath -> transformation interpretation event xml > Jexl -> transformation interpretation event xml > DVSL -> transformation interpretation octet text > > Most notably, it can be seen how XSLT/JXPath/Jexl cover the > same exact space. > > This leads me to believe that XSLT (if properly instrumented) could > remove the need for the other two. Moreover, if this > instrumentation is > compatible with the XSLTC operation, it would be possible to further > enhance the performance by pre-optimizing the stylesheet during > pre-compilation. Big +1 for using standardized languages.... <snip/> > > So, the point is: compilation is useful only if its used to remove > operations that are not going to be needed. I would suggest that optimization and compilation are really two completely different things...??? > Here are my thoughts: > > 1) I've come to the conclusion that we need both generation-based and > transformation-based approaches. > > Why? > > well, the first is useful when you have non-xml data fed into > the view, > the second is useful when you have xml data fed into the view. Well, in the first case you can always generate XML from the non-XML and still only use transformation for the "template". This does mean always a separate process but is that a bad thing? In particular, it helps enforce a separation of data retrieval from data presentation at the "template" level... <snip/> > 2) stream based solutions are better than non-stream based > one because they *always* remove the parsing stage. > > 3) all template languages will need > a) variable expansion > b) conditionals > c) iterations > and nothing more! Are you sure they don't need to be Turing complete? I suspect so... > 4) verbosity of the syntax must be balanced: too few verbosity is > efficient but grows into obscurity (ie Perl), too much verbosity is > harmful because signal/noise ratio is reduced. Bah: with modern high resolution monitors and syntax highlighting/context sensitive/auto completing editors this is a specious argument at best... > 5) control should be inverted: the template must be a view, > it should be > 'pushed' the data in, it should not contain any data-pulling > logic other > than the one used to pull data from the dataset passed on by the > underlying controlling stage. Perhaps, but, consider for a moment the recent discussion on xmls-dev that pointed out that Continuations enabled languages enable pull based processing in a very simple to use way: perhaps your real presentation model isn't analogous to MVC at all (as you sort of seem to assume?). Perhaps a pipeline system really needs something completely different for it's "architecture" (in a loose sense)? What happens if we completely remove any HTTP (stateless/stateful) assumptions and deal only with life cycled data sets that happen to have a presentation rendering riding on top of them (going along for the ride as it where). Combining pull based models on top of streams seems inherently unworkable until you have Continuations, but once you have them then you can think of the stream as being continually persistent and presentation rendering pulling only what is needed at the points the flow engine tells it to... > IMHO, the template language which is closer to the optimum is > XSLT but only with one change: > > FORGET THE XML SYNTAX! > > I'm entering wild mode now, so bear with me. Suppose you had: > > 1) a syntax that is simple and efficient to describe a stylesheet > 2) a defined object model accessible thru regular path queries > 3) no ability to call extensions No thanks; why reinvent the wheel? It seems only because of your assumption 4) and that I don't think justifies the end. However (playing devils advocate for a moment), I will note that SGML allows for more compact notations than those used by XML... > > Let me give you an example of what I mean. First of all, let > us assume > that the template engine assumes an xml-izable representation > of all the > data it has access to. It's a transformation in other words? <snip on example/> > > the above should be parsed, transformed into a regular xslt > stylesheet > and fed into a normal XSLT processor with extensions. > > The above will then be: > > 1) useful for both generation and transformation (the input object > will be empty and the / template would be called) Hmm, I have transformations where the input object is empty. (Abstractly) I use that to determine that the user is doing a search instead of displaying a result set... But then, I don't think you're using that as a way to control which is chosen, just after the fact to handle either case. However, is that really needed? Is there a real use case for reusing the template in this way that isn't covered by generation feeding transformation? > What do you think? Interesting, but I don't see that it really buys me anything I don't already have with XSLT except the requirement to implement and maintain Yet Another Language (YAL(tm))...
