Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
<snip/<
Or maybe a good solution can be to combine both approaches: the sitemap engine will use the mini-processor approach, and component lookups (which are not that often used) lead to the creation of a simple wrapper object implementing the Java interface, but that doesn't care about caching as SWT and ZipArchiveSerializer don't care about it.
Yes, this sounds like a good compromise. I really think that
the usage of VPC should not be any different than using
"usual" pipeline components - it should be transparent.
I agree that looking up sitemap components outside of the
tree processor does really happen not very often, so
providing such a wrapper is the best way to go.
Cool, we found an efficient solution :-)
So, for implementation VPC the only missing piece is resolving
of relative sources, right?
Yep. Problem is that currently the "src" attribute is a raw string and so we don't absolutize URIs at the place where they're written but at the placed where they're used, i.e. potentially in another context.
So we can enforce the contract of "src", stating that it *is* a URI, and thus absolutized by the sitemap engine at statement execution time. We have to perform extended checks that no component uses it another way though. Or we could have a marker interface extending SitemapModelComponent that could be used to distinguish the component's expectations.
We also need an absolutizer input-module that allows people to absolutize URIs used in other attributes than "src". That works pretty well using the nested variables resolution we have now, e.g. <map:parameter name="blah" value="{absolutize:data/{1}.xml}"/>
WDYT?
hmmmm. let's try to keep it simple and stupid. Today we have
<map:generate src="file.xml"/>
that means
1) type="file" is implicit because it's the default generator for these pipelines
2) "file.xml" is expanded to the local context of the pipeline (basically, where the sitemap.xml file is located).
Now, the question you pose is: what if the component needs to access a source of a VPC that is not local?
You won't.
It's wrong, IMO, that you have to know something about the resource internals of another block, it weakens the contract for no reason (because there should be no way for a block to expose its internal resources)
So, what if you have a transformer and the stylesheet is located in another block?
What you depend on its not the (transformer,stylesheet) couple but the (transformation) contract that is performed by these two working together.
So, instead of
<map:transform type="xslt" src="block:skin:/blah2html.xslt"/>
you do
<map:transform type="blah2html"/>
with no source.
What is left to describe is how we define how to go from "blah2html" to the actual implementation of that VPC.
Without thinking about intra-block communication, it would be as easy as defining a pipeline component as a pipeline fragment in the block sitemap (or in your own, if you want).
<map:transform name="blah2html"> <map:transformer type="xslt" src="blah2html.xslt"/> </map:transform>
but how can another block access this?
Each block has a descriptor that identifies:
1) the URI of the block 2) the names of the VPC that it exposes
the names of the VPC that it requires can be inferred from the sitemap and therefore don't need to be listed explicitly there ( to avoid duplication of effort and synch issues).
So, what if the VPC is defined in another block? You do:
<map:transform type="skin:blah2html"/>
and the sitemap will transform will know how to get it because, at deployment time that "skin" prefix will have been wired to the appropriate block URI and therefore the sitemap component manager will be able to identify it univocaly.
Now, look at this:
MyBlock depends on Block http://apache.org/cocoon/wiki/1.0 and reference it locally as "wiki" and contains the following in one of its pipelines:
<map:generate type="wiki:wiki2xml" src="whatever.wiki"/>
at deployment time, we have wired that dependency to block http://blah.org/myblocks/mywiki that implements http://apache.org/cocoon/wiki/1.0 and therefore exposes the following in its sitemap
<map:generator name="wiki2xml"> <map:generator type="wikiparser"/> <map:transformer type="xslt" src="stylesheets/chaperon2wiki.xslt"/> </map:generator>
<map:generator name="wikiparser" class="myclasses.WikiParser"/>
WDYT?
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
