cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] the quest for the perfect template language
Date Thu, 03 Apr 2003 16:43:15 GMT
Stefano Mazzocchi wrote:
<snip reason="agree"/>
> 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.

Here I agree even more ;) The choice of data to push into the template 
should be performed in the sitemap or in the flowscripts. Furthermore I 
think that generators and transformers should be free from side effects.

Ideally, IMO, generators can read data that is pushed from the 
environment by the control mechanism, (sitemap and flowscripts). 
Transformers just transforms input to output and has no connection to 
the environment, (this is probably overly restrictive in practice). 
Serializers can push data into the environment, see [1] for my view on 
this. The data can then be manipulated in whatever procedural way by the 

>                                  - o -
> IMHO, the template language which is closer to the optimum is XSLT

Wow!!! :)

We decided to follow that path at the company that I work for a little 
bit more than two years ago and have (at least most of the time) been 
happy with that. We are basically using XSLT as a generator as well and 
use an extended version of the TraxTransformer makes a larger part of 
the object model available as parameters. We have written a number of 
webapps in this way. No doubt, we have found and used a couple of anti 
patterns :/ during this work, but most of the time it has worked well 
and beeen productive.

> but only with one change:

I tend to agree, after having refactored a number of XSLT intense 
webapps written booth by myself and by other people, I have been forced 
to the conclusion: it is fairly easy to write XSLT (when you are used to 
it), but it migth be a hell to grasp what it does when you read it.

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

Dare I hope that "input:" refers to the inputstream? :P It could also be 
usefull with multipartinput: (see [2,3]).

> request:
> ...
> session:
> ...
> deli:
> ...
> flow:
> ...
<snip>code example</snip>

Your syntax looks quite good and is fairly simmilar to XQuery, (see the 
examples in [4], e.g.). XQuery has been described as "XQuery = XSLT - 
templateRules - nonAbbreviatedXPathAxes" [5], this might not be the 
whole truth, but from a syntax point of view I think that:

   XQuery + templateRules + nonAbbreviatedXPathAxes - XPath2 specific stuff

could be a good syntax. If XQuery gains popularity we would get editor 
support for and (partial) language descriptions for free.

"request::lang" etc, could be translated to the the XSLT function 
"document(request:/lang)", where "request:" is a Source. With the new 
Source and XSLTProcessor implementations from excalibur we get cashing 
for free if the parameter to the document function is determinable at 
compile time.

We would thus need to write (xml-)sources for all parts in the object 
model, and for other kinds of data that we would like to use our the 
template language. This could easliy be done with e.g., 
that was mentioned at xml-apache-general today, [6]. To make cashing 
depend on more specific and to gain efficency for large input data 
structures, one could implement xpointer functionality for some of the 


> the above should be parsed, transformed into a regular xslt stylesheet 
> and fed into a normal XSLT processor with extensions.

One could prototype the idea by using the Chaperon transformer and the 
cocoon protocol for transforming the src-input to the TraxTransformer.

> The above will then be:
>  1) useful for both generation and transformation (the input object will 
> be empty and the / template would be called)

We normaly use the pattern:

<map:match pattern="foo.html">
   <map:generate src="empty.xml"/>
   <map:transform src="foo.xsl"/>

(where empty.xml contains "<empty/>"), for using XSLT as a generator, 
but it would probalbly be a good idea to write a TraxGenerator. This way 
  we could also make different parts of the environment availabe in the 
TraxGenerator and the TraxTransformer (if this is desired).

Side effects

I cannot help but throwing in some wild RTs:

   We need an TraxSerializer as well ;)

As discussed earlier [7], I belive that the basic processing cycle for 
webapps should be as follows:

1. The flowscript call the sitemap for generating a page that is send to 
the browser (output pipeline).
2. The flowscript call the sitemap for taking care of the posted input 
from the browser (input pipeline).
3. The flowscript processes the data from the input pipeline and migth 
call business logic.

The task of the input pipeline is to gather and possibly change format 
of the input and to store the (xml)-data in some object model objects 
that therafter can be further processed by the flowscript. An example of 
such an object could be the form model for form handling.

A way to achive this would be to package the parts of the object model 
that we want the pipeline to be able to modify as ModifiableSource. The 
modifiable sources should only be available in the TraxSerializer and 
that would enforce that the template generator and transformer are side 
effect free. The serializer template could then do things like:

<xsl:result-document href="formdata:/├║serdata">
     <name><xsl:value-of select="name"/></name>

Unfortunately xsl:result-document is only a part of XSLT2.0. There is
a corresponding tag exsl:document in EXSLT [8]. Most XLST implementaions 
  has propetary extensions for multiple output documents, but those in 
Xalan and XSLTC seem to asume that the output should be a file. Saxon 
seem however to have a construction that use a source resolver.

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

I think it is an excelent proposal, an XSLT based template language with 
  XML access to the object model would replace a large part of the 
existing tag languages within Cocoon, it would also replace quite a few 
generators and transformers. It would also make it easier to learn 
Cocoon for new users and Cocoon would be percieved as much more coherent.

There are a some template languages where I don't see a natural fit to 
XSLT: ESQL or the SQLTransformer. The chart transformer from Fins have 
xml input and output and is side effect free and could (at least in 
principle) have been implemented in XSLT. It is however (for good 
reasons ;) ) implemented in Java instead by using JFreechart. The 
mentioned examples could be implemented as extension tags in XSLT, but 
as long as the interfaces for extension tags not are standardized that 
would be a maintainance nightmare. I would also open up for all kind of 
abuses. So I don't think that XSLT could replace all template langages 
that are used in Cocoon, but still a large share of them.

                     -- o --

To continue we need to define a syntax and a translation scheeme to XSLT 
for the new template language so that we can write a parser. We also 
need to define the XML-view and thew url-space for the object model so 
that we can start to write sources.

When do we start? ;)

/Daniel Fagerstrom


[1] The thread: [RT] Input Pipelines: Storage and Selection (was Re: 
[RT] Input Pipelines),
[2] Re: StreamGenerator depends on Servlets!!! (input pipelines 
[3] Re: [RT] Better Environment Abstraction,
[4] XML Query Use Cases,
[5] XQuery, XSLT "overlap" debated,
[6] Re: Accessing java beans through DOM,
[7] [RT] Input Pipelines (long),
[8] exsl:document,

View raw message