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

[Nicola Ken Barozzi <ni...@apache.org>]

Andreas Hartmann wrote:
...
> I think we need the following functionality:
> 
> - a request is matched in the generic sitemap
> - it should be possible
> 
>   a) to check if there is a specific sitemap with a pipeline
>      matching the same request
> 
>   b) to check if there is a pipeline in a (required) specific
>      sitemap matching the same request
> 
>   c) both of these (if the sitemap exists *and* the pipeline
>      exists)
> 
>   and when the check succeeds, to mount the specific sitemap.
> 
> Case a) can be solved with dynamic mounting
> (http://wiki.cocoondev.org/Wiki.jsp?page=SitemapPatterns)

Gosh, I didn't check if it works, and I thought it didn't anymore. Good 
to know, I'll use that :-)

> 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 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?

> 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?

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.

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}"/>

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



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

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

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

[Robert Koberg <ro...@koberg.com>]

Hi,

> Also, it seems to me that the sitemap DTD has a lot in parallel with
> XSLT. In the case of XSLT, overwriting is solved by having "import"
> versus "include". 

Or, you could use a URIResolver. 

First, you have a smaller tree to compile/cache than when using xsl:import.
You don't add more to it, but still get the same result (the override). 

  --o--

Second, say you have multiple views to support. To keep it simple, let's
just say there is preview, edit and generate (to html) and we have the case
of linking internal documents. 

- in preview you resolve to one include that handles an in-cms-app linking
scheme (javascript: perhaps)

- in editing you can resolve to something that throws up a link editor GUI

- during site generation you can resolve to something that provides a
document relative URI for the link.

  --o--

Third, you can host multiple projects/publications. If you know the base
path/name of the user's project (or more likely a Project object) you can
use that in the resolver to first check the project location, if not there
then get it from a default location.

Make sense?

-Rob


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

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

[Michael Wechner <mi...@wyona.com>]

Nicola Ken Barozzi wrote:


<snip />

> 
> Ah, so you are talking about named pipelines and using them for 
> functionality. In practice, what do you use named pipelines for in Lenya?

btw, "unique labeled pipelines" would also allow easy debugging. The 
labels yould be written into the log file and then be analyzed easily.
The analyzer would be able to show you through which pipelines/resources 
your request went. Would be very nice for more complex sitemaps.


> 
> 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?

Well, I guess many people already had, have or will have the same problem.
Within Lenya we had this problem pretty much from the very beginning.
I posted it twice, e.g. most recently
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=105792815917274&w=2


One could view a pipeline just as another "method" of a specific 
programming language with a pipeline characteristic, but not being 
called by its "method name" (as resources are), but being called through
matching the request. But I guess exactly this small difference how
a method is being "called" makes it a big difference.


I have never studied "programming languages" (e.g. when is something a 
programming language etc.), but I have recognised this fight to not 
invent another programming language, etc. for several times now.


Also, it seems to me that the sitemap DTD has a lot in parallel with 
XSLT. In the case of XSLT, overwriting is solved by having "import" 
versus "include". Maybe one could introduce another kind of "mount" 
statement.

Thanks

Michi




> 
>> 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?
> 
> 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.
> 
> 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}"/>
> 


-- 
Michael Wechner
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://www.wyona.com              http://cocoon.apache.org/lenya/
michael.wechner@wyona.com                        michi@apache.org



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

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

[Guido Casper <gc...@s-und-n.de>]

Nicola Ken Barozzi <ni...@apache.org> wrote:
> 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.

Are you sure? I think the cocoon: protocol grabs the SAX events just
before the serializer. So one can have an externally available pipeline
with HTMLSerializer (or any other) but still get the XML with the
cocoon: protocol.

Guido


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