RE: Source Resolving in Virtual Pipeline Components (was Re: [RT] VirtualSitemap Components)

[Carsten Ziegeler <cz...@s-und-n.de>]

Sylvain Wallez wrote:
> 
> IMO, we really need the "context:/" (single slash) we talked 
> about some time ago, that resolves relatively to the 
> currently executing sitemap (i.e. the one defining the VPC). 
> Relative sources (with no protocol) must always be resolved 
> relative to the sitemap where the VPC is called. 
> However, the implementation of some VPCs, just as in my 
> example above, needs some resources to be resolved relative 
> to the sitemap in which the VPC is defined.
> 
> So my example could be rewritten as follows:
> 
> <><map:virtual-generator type="foo">
>   <map:generate src="{src}"/>
>   <map:act type="lang-select">
>     <map:transform type="i18n"/>
>   </map:act>
>   <map:transform type="xslt" src="context:/stylesheets/{bar}.xsl/>
> </map:virtual-generator>
> 
> That way, there is no magical absolutization applied.
> 
> Thoughts?
> 
Yes, this is the "no magic" solution :) which works and which is not bad,
but I see one potential problem for users:
You have a different behaviour in the same sitemap if you use:

   <map:transform type="xslt" src="tylesheets/bar.xsl/>

in a virtual component or in a regular pipeline. And this is imho very
difficult to explain. We will get thousands of requests saying:
"Why can't this nice Cocoon not find my stylesheet"?

My first idea was to do it the other way round, so if you want to
access a resource of the current sitemap (not the sitemap the VPC
is defined in) you use a special protocol (I just name it 'current'
for the sake of the example):

 <map:virtual-generator type="foo">
   <map:generate src="current:{src}"/>
   <map:act type="lang-select">
     <map:transform type="i18n"/>
   </map:act>
   <map:transform type="xslt" src="stylesheets/{bar}.xsl/>
 </map:virtual-generator>

If in the example from above, {src} is relative, it's resolved relative
to the current sitemap; if it's absolute 'current:' is ignored.
But for me this looks a little bit ugly as well...

Hmmm.

Carsten

Re: Source Resolving in Virtual Pipeline Components (was Re: [RT] VirtualSitemap Components)

[Sylvain Wallez <sy...@apache.org>]

Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>  
>
>>IMO, we really need the "context:/" (single slash) we talked 
>>about some time ago, that resolves relatively to the 
>>currently executing sitemap (i.e. the one defining the VPC). 
>>Relative sources (with no protocol) must always be resolved 
>>relative to the sitemap where the VPC is called. 
>>However, the implementation of some VPCs, just as in my 
>>example above, needs some resources to be resolved relative 
>>to the sitemap in which the VPC is defined.
>>
>>So my example could be rewritten as follows:
>>
>><><map:virtual-generator type="foo">
>>  <map:generate src="{src}"/>
>>  <map:act type="lang-select">
>>    <map:transform type="i18n"/>
>>  </map:act>
>>  <map:transform type="xslt" src="context:/stylesheets/{bar}.xsl/>
>></map:virtual-generator>
>>
>>That way, there is no magical absolutization applied.
>>
>>Thoughts?
>>
>>    
>>
>Yes, this is the "no magic" solution :) which works and which is not bad,
>but I see one potential problem for users:
>You have a different behaviour in the same sitemap if you use:
>
>   <map:transform type="xslt" src="tylesheets/bar.xsl/>
>
>in a virtual component or in a regular pipeline. And this is imho very
>difficult to explain. We will get thousands of requests saying:
>"Why can't this nice Cocoon not find my stylesheet"?
>  
>

I understand your point. On the other hand, this is what currently 
happens with source resolving in a Java component, since even if the 
component is declared in a parent sitemap, sources are considered 
relative to the location where the component is used.

And that's the "where the component is used" that is problematic here, 
as this now means two things: either the caller or the callee.

To add a bit of confusion, we can also have a virtual component in a 
parent sitemap using itself a virtual component defined in a 
grand-parent sitemap. We now have caller, intermediate callee, and 
upper-level callee, etc.

What's relative to what now?

I'm starting to think we'll never find a good solution to resolving 
relative URLs in this context. Maybe the solution is to be stricter and 
require sources to be absolute when used in virtual components. To 
achieve this, we can implement the "context:/" protocol that will 
resolve relatively to the sitemap at the deepest level (the one having 
the initial VPC call) and provide some "absolutizer" input modules that 
leverage the nested expressions now allowed in the sitemap, e.g. 
<generate src="{absolutize:{src}}"/>

That way, resolution becomes more predictable and we can provide users a 
meaningful error stating that they must use absolute URLs.

WDYT?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }