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="http://apache.org/blah/Blah"/> <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] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103787313407324&w=2
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="http://cocoon.apache.org/services/generation/File"; src="blah.xml"/>
<transform type="http://cocoon.apache.org/services/transformation/blah2html"/>
<serialize type="http://cocoon.apache.org/services/serialization/html"/>
and this solves *ALSO* the issue that was identified at the GT about "virtual pipeline components" resolving services locally or remotely (block-wise).
- 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.
*AND*
last but not least,
it would finally introduce a real "pipeline level" polimorphism that will allow the creation of real blocks.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
