cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] the quest for the perfect template language
Date Mon, 07 Apr 2003 17:19:45 GMT
on 4/6/03 11:48 AM wrote:

> Stefano Mazzocchi wrote:
>  > Daniel Fagerstrom wrote:
>  >> Stefano Mazzocchi wrote:
> <snip/>
>  >> Furthermore
>  >> I think that generators and transformers should be free from side
>  >> effects.
>  >
>  > I agree, but it's going to be hard to enforce this. It might come up as
>  > a general 'design pattern' later on, when enough common knowledge is
>  > gained, collected and distilled.
>  >
>  > But I think that would take years.
> I'm certain that you are right, some programmers can be so conservative.


> The JSP/ASP/PHP (anti-)pattern about how to write webapps will propably
> be rooted in a lot of programmers minds for years. Not easy to change.
> Really good code examples and style guides for how to use Cocoon could
> help at least a litle bit I believe.

those will emerge with time, don't worry.

> For XSLT-based generators and transformers however, uncontrolled use of
> side effect is a really bad idea. First the specification doesn't say
> anything about execution order, execution order might be implementation
> as well as optimization level dependent. 

execution order of what? I can't follow you.

> Ok, as most implementations
> allows for extension order that might have side effects the implementors
> probably would not do anything such against its user base.

the extension mechanism is faulty and the xslt archiects know this.
still, without a portable language, they can't mandate any way for
extensions to be crossplatform unless they dive into IDL/CORBA
language-abstracton problems.

I don't even want to know what kind of "my language is better than
yours" battles happened in side the XSL WG, but I only guess that java
vs. .NET roared for sure :-)

> Second, if you avoid side effects in booth generators and transformers
> you can afford the simplified mental model that the pipeline steps are
> executed one at a time. If you update the same environment object booth
> in a generator and a transformer, you have to take the streaming in to
> account. Despite that I should know better I have done this mistake more
> than once, and now I firmly believe that side effects in transformers is
> an anti pattern.

Might be, I really don't know nor have enough information to provide. I
never used a transformer with side effects, nor found the need for one

>  > oh, yes, I thought about that too, but, gosh, I hate document() so much.
> Why?

Gut feeling. Maybe I'm just being too conservative myself :-)

I'm fully willing to reconsider it in the future anyhow.

> In another mail you said:
>  > Two things worry me:
>  >
>  >  1) performance: document() is a push-based function. We can't have
>  >  a call to a cocoon pipeline for each and every variable I need.
> Variables - request parameters e.g., are read from a source that 
> basically is a adapts the request object to dom tree or sax events, I 
> don't see why that would be slow or why the cocoon pipeline should be 
> called. Or did I miss something?

suppose you have an XSP-oriented approach: you do

 <request:parameter name="blah"/>

which gets translated into something like


now you have something like


which is translated into

 <xsl:value-of select="document('cocoon://request/blah')"/>

which will:

 1) take the request object

 2) saxify it to an xpath engine

 3) wait for the right even to come

 4) create a nodeset

 5) pass it to the stylesheet

 6) lookup the node value

This is potentially *orders of magnitude* slower.

>  >
>  >  2) caching (related to the above): how do I know if the result is
>  >  cacheable if I have no hooks to the document() engine?
> You have a hook to the document function. The TraxTransformer uses 
> org.apache.excalibur.xml.xslt.XSLTProcessorImpl, that handles a source 
> resolver to the XSLT implementation, the source reolver is that from the 
> Cocoon ComponentMananger wraped with a thin layer that saves all the 
> uri:s that are resolved and uses this for the validity object for the 
> transformer. This works very well for includes and imports in Xalan as 
> these are resolved during "compile time". The document function use the 
> same resolver and if the uri to a document function is known at compile 
> time it could at least in principle reolve the uri then and thus get 
> cashing. I don't know if that actually is done in Xalan and XSLTC, I 
> will take a look at the code. Any one know anything about this?
>  > What about XSLT extensions?
> I don't think using XSLT extensions is an option as they only are 
> executed during run time and cashing AFAIU must be handled during 
> "compile" time.

??? I don't follow you.

> <snip/>
>  > agggggghhhhhhhh, forking pipelines again!!! :-)
>  >
>  > No, seriously, I think there is value in giving the serializer the
>  > ability to access the object model, both for reading and for writing,
>  > but having serveral side effects... hmmm, that would also require a
>  > pretty good knowledge of the DOM-like shape of all the objects given to
>  > the stylesheet which might be kind of hard.
> As I said above I believe that using side effects in an uncontrolled way 
> in pipelines creates problems. What I had in mind for the serializers 
> was a very restricted form of side effect. Things like puting a dom tree 
>   in a request parameter or FOM variable and write to a file or and 
> XMLDB, maybe one could initialize java objects from xml an put them in a 
> FOM variable. The main idea is to make it easy to package input data in 
> such a form that it is easy to manipulate it in flowscripts. I think it 
> would be a bad idea to write procedural programs in a serializer. My 
> ideas about this is still quite vague.

I see.

What would you think of something like


so that you pass a dom/jdom object that gets populated by the pipeline
you call from the flowscript?

that way you could extract information (using jxpath, for example) then
discard it or serialize it later by yourself.

I'm quite in wild mode right now so take with with very foggy idea that
just popped up.

> <snip/>
>  > but we would then need to reparse those streams to regain the data and
>  > remarshall it to the data objects. I see your point and I think it could
>  > be pretty powerful from a usability perspective (compared to write your
>  > own serializers that do objectmodel writes directly) but I'm not sure we
>  > really need that complexity right now.
> Agree, lets focus on the generator and transformer part.
> <snip/>
>  >> 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.
>  >
>  >
>  > Hold on, let's try to apply some SoC:
>  >
>  > first concern: non-xml syntax
>  > -----------------------------
>  >
>  >  1) it should reduce verbosity to a minimum, yet be terse enough not to
>  > result cryptic.
>  >
>  >  2) it should reuse standard syntaxes (xpath, xquery) as much as
>  > possible (reduce wheel reinvention to a bare minimum)
> I took a more detailed look at xquery, lots of constructions look very 
> good in it, but it is a language in the SQL (and COBOL) tradition, so it 
> is supposed to look like english sentences. That is quite ok for a 
> specialized language like SQL and XQuery, but it might be unpractical 
> for a more general language like XSLT. XQuery is still great as a source 
> of inspiration for the non-xml syntax but maybe it is better to design 
> something a little bit more C-like. The XPath syntax should be used as is.

I tend to agree with you.

>  >
>  >  3) it should be only syntax sugar on top of XSLT (with eventually some
>  > extensions) so that it can be automatically translated to XSLT.
> Yes, there should defintly be a choice, if one want to use XML or 
> non-XML syntax.
> An important design choice is if there should be a complete 1-1 maping 
> between the XML and non-XML syntax.


>  > second concern: access to the object model
>  > ------------------------------------------
>  >
>  >  1) it should allow access read access to the cocoon object model in an
>  > efficient way.
>  >
>  >
>  > third concern: use of XSLT for generation
>  > -----------------------------------------
>  >
>  >  1) it should allow the use of literal result elements stylesheets
>  >     [] as templates
>  >     for a generator
> I took a look at the TraxTransformer, it should be easy to write a 
> TraxGenerator, and if we use sources for embeding the OM one could 
> remove more than half of the code as it handles parameters to XSLT, wich 
> we wouldn't need anymore.

right, but my problem with document() performance still remains, even
compared to <xsl:param> or {$request} what do you think about that?

>  > The three concerns are fully isolated and can be independently
>  > implemented/designed.
>  >
>  > I think the most important one is the access to the object model,
>  > followed by the use of XSLT for generators and then, at the end, come up
>  > with a better syntax.
> Seem like a good plan.


>  > I'm personally more oriented to see the object model accessed thru the
>  > use of xslt extensions than thru the use of the document() function. But
>  > this yields the problem of lack of portability between extensions which
>  > I know nothing about.
> I would guess that for extension fuction the portablity problems would 
> be managable. For extension elements it is probably much worse as they 
> need access to some internals of the transformer. We still have the 
> cashing problems that I discussed above. One possiblity would be to scan 
>   the xslt program and look for our OM extension functions and 
> calcualate cashing based on that, but It seem like a hack for me.
> <snip/>
>  > XTTL stands for eXtensible Transformation and Template Language so we
>  > finally get rid of that useless "style" concept for transformations
>  > which should only belong to CSS.
> Great, I started to wory about what to call it :)
>  >
>  >> When do we start? ;)
>  >
>  >
>  > I would suggest waiting for after we release 2.1
> Ok, depends on how soon that will happen ;)

well, that's very hard to tell :-)


View raw message