cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dani...@lentus.se
Subject Re: [RT] the quest for the perfect template language
Date Sun, 06 Apr 2003 09:48:38 GMT
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.

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

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.

<snip/>
 >> Dare I hope that "input:" refers to the inputstream? :P It could also
 >> be usefull with multipartinput: (see [2,3]).
 >
 >
 > It could, but this reminds me of forking pipelines and I don't get a
 > nice impression out of this.
 >
 > i think it should be the underlying controlling logic to drive what
 > 'part' of the input stream (consider it multiparted) should be 
elaborated.
 >
 > it is trivial to add a 'part selection' capability to the 
StreamGenerator.

Ok, I have never implemented any webapps that make serious use of
multipart mime, so I realy don't know.

<snip/>
 > oh, yes, I thought about that too, but, gosh, I hate document() so much.

Why?

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?

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

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

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

 >
 >  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
 >     [http://www.w3.org/TR/xslt#result-element-stylesheet] 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.

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


/Daniel Fagerstrom






-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Mime
View raw message