cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] applying SoC on cocoon itself
Date Mon, 18 Oct 2004 22:32:48 GMT
Sylvain Wallez wrote:

> Stefano Mazzocchi wrote:
>> Pier made me realize that there are 3 different issues on the table 
>> regarding real blocks:
>>  1) classloading isolation
>>  2) pojoification
>>  3) service isolation
>> and, interestingly enough, they are orthogonal.
>> Tani was born to prototype 1.
>> Butterfly was born to prototype 2.
>> But what I really care is 3!!! and Pier made me realize that you don't 
>> need to have neither 1 nor 2 to achieve 3!!!
>> The key is *very* subdle and, in fact, was hard for me to realize before.
>> Let me show you with an example:
>>  <map:transformer name="blah" class="org.apache.blah.Blah"/>
>>  ...
>>  <map:transform type="blah" src="blah.src"/>
>> This design is 5 years old and does *THIS* really mean? it means that 
>> the sitemap will lookup a "component" identified by a "class" cast it 
>> to the functional group (in this case, a transformer), reference it 
>> with its local name and used with further parameters (the src="").
>> Now, look at this
>>  <map:transform name="blah/*" uri=""/>
>>    <map:param name="src" value="{1}.src"/>
>>  </map:transform>
> Can you elaborate on this syntax? This reminds me of the pipeline 
> services we discussed about 2 years ago [1] (wow, already? Time goes 
> fast!), but I don't understand the pattern in the transformer name 
> (blah/*).
> Sylvain
> [1]

There was always something that bothered me about the differnce between 
a generator/transformer and a serializer. the first two had the src="" 
attribute and the other ones did not.

Moreover, the "fo2pdf" serializers never existed. It was a "Serializer" 
that was identifying the "shape of the java class" and the 
"FopSerializer" that was identifying the implementation of that class, 
but there was never anything that defined the "service" that made 
iTextSerializer and FopSerializer interchangeable.

It made me realize how the use of java classes as identifiers for the 
service behaviors is limited! And it's also the reason why cocoon block 
are not avalon blocks on steroids, but are entirely different things.

So, what's with the above?

There are two types of transformers: compiled and interpreted. for XSLT 
transformations we have both: xalan and xsltc. But what's the similarity 
between the two?

  <map:transform type="xslt" src="news2html.xslt"/>

is really saying:

  transform the sax stream using the logic contained in the 
news2html.xslt stylesheet.

but then

  <map:transform type="xslt/news2html"/>

could mean *exactly* the same, where the news2html file was 
"precompiled" into a xsltc translet, and here just identified.

But there is more, the above could well be

  <map:transform type="news2html"/>

All represent the *same exact* pipeline service and, in principle, it 
should not be your concern on how this service is implemented, and not 
even *which* block exposes it!

Now, let's get to another thing that always bothered me:

  1) generator src="" -> "what"/"how"
  2) transformer src="" -> "how"
  3) serializer -> none

the use of the src="" attribute makes sense in generators but doesn't 
really make sense in transformers. and in generators, in fact, it's 
nothing more than a parameter that is passed to the generator. Unless, 
ofcourse, the generator is a server page generator, so the src="" 
represent the "what" for the component and the "how" for the pipeline.

What does all this mean?

when you say

  <generate type="file" src="blah.xml"/>
  <transform type="xslt" src="blah2html.xstl"/>
  <serialize type="html"/>

you are really stating something like

  <generate type="" 
  <serialize type=""/>

and this solves *ALSO* the issue that was identified at the GT about 
"virtual pipeline components" resolving services locally or remotely 

                            - o -

In short: we use the avalon component model for the sitemap machinery 
and that heavily influenced its design. Pojoification is one thing, but 
servification of the pipeline machinery would allow a *far* better reuse 
of pipeline services, implemented both as compiled components, 
interpreted components or virtual components.


last but not least,

it would finally introduce a real "pipeline level" polimorphism that 
will allow the creation of real blocks.


View raw message