Re: User Pipeline Customization (was Re: [RT] Reconsidering usecases and tasks)

[Andreas Hartmann <an...@apache.org>]

Nicola Ken Barozzi wrote:

[...]
> 
>> The other cases require a mechanism to look for a certain
>> pipeline (with the same id/label?) in another sitemap.
>>
>>   <map:pipeline label="publish"
>>       refined-by="pubs/{page-envelope:publication-id}/usecase.xmap">
>>     ...
>>   </map:pipeline>
>>
>> (I'm not sure if runtime parameters can be used in the
>> pipeline setup at all)
> 
> 
> Ah, so you are talking about named pipelines and using them for 
> functionality. In practice, what do you use named pipelines for in Lenya?

You mean there is the concept of named pipelines?
I just searched in the Wiki, but didn't find anything.
Would you mind pointing me to a resource?

> You know what? We may need this even more. I mean, I had the same need I 
> think.
> ATM we are reusing pipelines calling internal URIs with the cocoon: 
> protocol, but it *sucks*, as the xml is always serialized and 
> deserialized at every cocoon: step. So it would be better to use 
> <resources> for that but, heck, we cannot mount those IIUC.
> 
> Is this a common use-case?

We're using the cocoon:/ protocol very frequently, mainly
for aggregation. It is convenient and easy to understand
(IMHO it makes sitemaps more readable then resources do).
Maybe it could be possible to avoid serialization and just
pass on the SAX stream?

>> I could also imagine something like "sitemap inheritance".
>> I guess in this case the inheriting sitemaps would have to
>> be known at compile-time and the corresponding pipelines
>> would have to be replaced. But I'm not aware of all the
>> consequences of such a concept.
> 
> You mean sitemap or pipeline fallback?

Actually, I thought of something like

<map:sitemap extends="../sitemap.xmap">

   <!-- pipeline replacing a super-sitemap pipeline -->
   <map:pipeline label="foo">
     ...
   </map:pipeline>

</map:sitemap>

But then all inheriting sitemaps would have to be found
before the super-sitemap is compiled/interpreted.

> I mean, the follwing will not work:
> 
> <map:match pattern="*/**-info.html">
>   <map:act type="resource-exists" src="{1}/info.xmap">
>     <map:mount src="{1}/info.xmap" uri-prefix="{1}"/>
>   </map:act>
>   <map:mount src="base/info.xmap" uri-prefix="{1}"/>
> </map:match>
> 
> What I would like to do with the above is to give {1}/info.xmap a shot 
> at processing the input if it's there, and if nothing matches, pass it 
> on to base/info.xmap.

Yes, Lenya is also suffering from this problem.
We're using the following concept as a workaround.
For each pattern that can be handled by a sub-sitemap,
a certain sub-sitemap is created (the usecase matcher is a
request parameter matcher)

<!-- mount publication-specific usecase sitemap -->
<map:match type="usecase" pattern="*">

   <map:act type="resource-exists"
            src="[...]/usecase-{1}.xmap" >
     <map:mount uri-prefix="[...]"
                src="[...]/usecase-{../1}.xmap" />
   </map:act>

</map:match>

E.g., the pattern "publish" is handled by the sub-sitemap
"usecase-publish.xmap", if the sitemap file exists.
This is not very nice, but it works.

> Probably it would work if I do
> 
> <map:match pattern="*/**-info.html">
>   <map:act type="resource-exists" src="{1}/info.xmap">
>     <map:mount src="{1}/info.xmap" uri-prefix="{1}"/>
>   </map:act>
> </map:match>
> 
> and in each info.xmap I add this at the bottom:
> 
> <map:mount src="base/info.xmap" uri-prefix="{1}"/>

It probably would, but it looks quite dangerous regarding
mount loops ... :)

-- Andreas




---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org