cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] applying SoC on cocoon itself
Date Wed, 20 Oct 2004 21:02:41 GMT
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.


Mime
View raw message