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 flowscripts.
- 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:
FORGET THE XML SYNTAX!
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]).
<snip>code example</snip>request: ...
session: ...
deli: ...
flow: ...
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. domify.sf.net, 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 sources:
document(hugedb:/foo#xpointer(//bar[3]))/foo.
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"/> <map:serialize/> <map:match/>
(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">
<user>
<name><xsl:value-of select="name"/></name>
...
</user>
</xsl:result-document>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
References ==========
[1] The thread: [RT] Input Pipelines: Storage and Selection (was Re: [RT] Input Pipelines), http://marc.theaimsgroup.com/?t=104193709500001&r=1&w=2
[2] Re: StreamGenerator depends on Servlets!!! (input pipelines discussion, http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104040197622745&w=2
[3] Re: [RT] Better Environment Abstraction, http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104213670731308&w=2
[4] XML Query Use Cases, http://www.w3.org/TR/xmlquery-use-cases/
[5] XQuery, XSLT "overlap" debated, http://www.xmlhack.com/read.php?item=1080
[6] Re: Accessing java beans through DOM, http://marc.theaimsgroup.com/?l=xml-apache-general&m=104933707032752&w=2
[7] [RT] Input Pipelines (long), http://marc.theaimsgroup.com/?t=104008605100003&r=1&w=2
[8] exsl:document, http://www.exslt.org/exsl/elements/document/index.html
