cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Praher <jpra...@yahoo.de>
Subject Re: [RT] the quest for the perfect template language
Date Tue, 08 Apr 2003 09:06:23 GMT
hi all,

sorry to join this discussion a little bit late.

I agree with Stefano that the xml encoded xslt syntax can be a nightmare
whent it comes to readabilty and topisght. 

so on the syntax level a more expressive model is highly appreciated - 
especially parameter passing, calling templates and evaluation of
expressions is a pain right now - here the { } is really great.

<sidenote>
it is also funny that currently in  xslt there are 2 kinds of citizens

a) the built-in,extension functions
b) the templates and named templates

why can't I call a named template like a built in function ?
(orthogonality ;-) )
</sitenote>

But in my point the syntax is not the only problem, why xslts are so
hard to read and tend to be complex. The abilty to build a modularised
set of templates is currently very hard, extensions can not easily be
built other than having a scripting language or any other external
language binding mechanism.

surely one can always do a nifty design/hack by using cocoon to
dynamically generate a stylesheet and refere via
cocoon:/xyz-dyn-stylesheet to it, use the catalog urn rewriting system
or resource: uri handler (for generate it from any resource including a
jar file) and many things like that - but this should be realisable
within the framework/language instead of having to provide much effort
to make a custom solution. (which is different for every
developer/company/organisation)

in the language itself more dynamism is very importannt. this is the
core demand for building more reusable cusomizable stylesheets, where
the user only overrided the points he would like to do in some other
way, that costs some efficiency but

a) you can optimize it 
b) abstraction always costs some performance
c) the stylsheets get much leaner and the processing/tree building costs
thereby reduce
d) often used libraries could easily be precompiled/compiled by a
caching system (using the code xsltc uses) 

when talking about dynamism, exslt:evaluate, for instance, is one of the
functions I need very often (but that are things that creep in xslt
processors only recently (xalan-j since 2.4.1) ).

also the ability to call named templates dynamically is a must have in
my opinion. 

the xslt:function in xslt2 is quite promising, but it would be great if
you could, syntactically call it using "myFunction( a, b)" instead of
<xsl:call name="myFunction"
><xsl:with-param>..</xsl:with-param></xsl:call>

to sum it up:
- ease the syntax of xslt, to be easier to write and read for humans
- use state of the art modularisation techniques (like we do it when we
use java)
- make it easy to build generic templates that can be put in a
repository and looked up via an import mechanism

there are many lessions we could learn from the dynamic language people
when it comes to building reusable customizable stylesheets. (like build
a conformance test into the stylesheet, so that source tree errors and
error detection can work much better).

my 2 cents

--Jakob

Am Mit, 2003-04-02 um 20.25 schrieb Stefano Mazzocchi:
> The more I use the flow inside cocoon, the more I think there is no way 
> back. Not only it enforces SoC, it also removes over-SoC, which happens 
> where you have your information scattered around the entire place (as 
> for PHP stuff, for example).
> 
> But 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
> 
> so, the chart is
> 
>                   +----------------------+--------------------------+
>                   |                      |                          |
>                   |     compilation      |      interpretation      |
>                   |                      |                          |
> +----------------+----------------------+--------------------------+
> |                |                      |                          |
> |   generation   |       XSP,JSP        |     Velocity,X:Forge     |
> |                |                      |                          |
> +----------------+----------------------+--------------------------+ 
> 
> |                |                      |                          |
> | transformation |        XSLTC         |  JXPath,Jexl,XSLT,DVSL   |
> |                |                      |                          |
> +----------------+----------------------+--------------------------+
> 
> 
> 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.
> 
> Now, first of all, with modern JVMs, it's not to know when compiled code 
> is more performant than interpreted code.
> 
> Under all circumstances, a java virtual machine runs on at least two 
> layers of emulation:
> 
>   1) java bytecode -> native bytecode
>   2) native bytecode -> internal CPU microcode
> 
> with technologies like Transmeta CodeMorphing or even Intel/AMD 
> CISC->RISC internal out-of-order instruction execution, the second layer 
> is still significant. For RISC-oriented architectures like PowerPC or 
> Sparc, the second layer is smaller, but still very important due to the 
> internal superscalar nature of modern CPUs.
> 
> Optimize code that will run on so many different execution environments 
> is very hard, if not impossible.
> 
> The only interesting approach, IMO, is the one taken by XSLTC: compiling 
> the stylesheet doesn't necessarely mean to *inline* the execution of 
> methods by unrolling loops (like it is done in XSP, for example), but to 
> remove those checks that are not necessary because the stylesheet has 
> been analyzed previously.
> 
> This is nothing different from what hotspot does, only that it does it 
> with run-time collected information.
> 
> So, the point is: compilation is useful only if its used to remove 
> operations that are not going to be needed.
> 
>                                   - o -
> 
> 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.
> 
> With the ability of cocoon pipelines, it's going to be harder and harder 
> to choose which approach is best as I find myself using *both* at the 
> same time in different situations.
> 
> 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!
> 
> 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.
> 
> 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.
> 
>                                   - o -
> 
> 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 xpath queries
>   3) no ability to call extensions
> 
> 
> 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.
> 
> So, for example:
> 
> input:
> <list name="whatever" xmlns:ns="http://whatever/">
>   <item xml:lang="en">blah</item>
>   <item xml:lang="it">blah</item>
>   <item>
>    <ns:subitem>blah</ns:subitem>
>    <ns:subitem>blah</ns:subitem>
>   </item>
> </list>
> 
> request:
> ...
> 
> session:
> ...
> 
> deli:
> ...
> 
> flow:
> ...
> 
> then we can have the following templatesheet:
> 
> namespace ("ns") {
>   "http://whatever"
> }
> 
> template ("/") {
>   <html>
>    <head>
>     <title>{list/@name}</title>
>    </head>
>    <body>
>     <form action="{flow::continuation/id}">
>      <table>
>       attribute ("width") {
>         if ({deli:screen-width}) {
> 	{deli:screen-width}
>         } else {
>          "100%"
>         }
>       }
>       apply-templates
>      </table>
>     </form>
>    </body>
>   </html>
> }
> 
> template ("item") {
>   <tr>
>    <td>
>     if ({ns:subitem}) {
>       if ({count(ns:subitem}) > 1) {
>         for-each ({ns:subitem}) {
>           <span style="color:green">{.}</span>
>         }
>       } else {
>         <span style="color:red">{.}</span>
>       }
>     } else if ({request::lang} == {@lang}
>             || {request:://cookie/lang} == {@lang}) {
>       {.}
>     } else {
>       "unknown language \"" {@lang} "\""
>     }
>    </td>
>   </tr>
> }
> 
> 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)
> 
>   2) compilable
> 
>   3) stream based
> 
>   4) reduced verbosity yet terse
> 
>   5) access to all cocoon object model and extensible
> 
>   6) namespace-capable
> 
>   7) declarative
> 
> What do you think?
> 
> P.S. the above syntax is rough and I think it's not that perfect, but a 
> terse yet powerful syntax is achievable.
> 
> Stefano.
> 
> 


Mime
View raw message