cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: [RT] the quest for the perfect template language
Date Wed, 02 Apr 2003 19:53:44 GMT
Stefano Mazzocchi <>


> 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....


> 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"


> 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:
> 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

> 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))...

View raw message