{list/@name}

Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E8B356D.6070409@anyware-tech.com>
Date: Wed, 02 Apr 2003 21:09:33 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3b) Gecko/20030210
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] the quest for the perfect template language
References: <3E8B2B2D.8070207@apache.org>
In-Reply-To: <3E8B2B2D.8070207@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:

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


<snip/>

> 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 exactly the approach taken in the treeprocessor, that led it to be 
a few % faster than the compiled engine.

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


Some restrictions on the push model : it requires the pushed data to be 
fetched by the flow before being processed by the view. Although this is 
fine in most simple cases, there are some applications where large 
datasets are used to build the view, and SAX-based streaming really is 
necessary (e.g. database extraction).

In that case, we must have an hybrid model where the flow pushed 
information that allows the view to pull its content. E.g. the flow will 
push the parameters of a SQL query which is executed by the view and has 
its result streamed.

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


I guess you mean that flow context is made available to the stylesheet 
through XPath-enabled variables, right ?

>  3) no ability to call extensions 

It's soooo useful to call some helper Java classes in XSLT to overcome 
the limitations of XPath...

<snip/>

> then we can have the following templatesheet:
>
> namespace ("ns") {
>  "http://whatever"
> }
>
> template ("/") {
>  <html>
>   <head>
>    <title>{list/@name}</title> 

<snip/>

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


<snip/>

> What do you think? 


You reinvented XSLScript ! It's at http://www.pault.com/pault/prod/XSLScript

Ah, and how does this fit with caching ?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }