Re: [RT] Using pipeline as sitemap components (long)

[Sylvain Wallez]

Carsten Ziegeler wrote:

Thanks Sylvain for this RT on a missing piece for the blocks concept.
More inline:

Sylvain Wallez wrote:

<snip/>

I don't see a need for a new sitemap element such as "map:call-pipeline" or "map:generate-from-pipeline". What we want is to generate and initial content in the current pipeline, and for this we just use a particular implementation of a generator, as we already do for files, XSP, etc.

I don't see the need for this special generator as the current components
(file generator - which has not the best name) do it already. Another
component would imho more confuse than help.

This generator is there for consistency with the transformer and serializer : a whole set is defined. Also, its implementation will be different and maybe allow better performance and/or caching than the current source (maybe not with the SourceValidity introduced in 2.1).

And what do you want to do with map:aggregate?

We keep the "cocoon:" protocol for this. But I always have been frustrated that map:part only accepts a simple "src", and would love to be able to put sitemap statements in it. But that's another story...

Pipelines as serializers
------------------------

<snip/>

How do we use this ? Well, just as for the generator, let's define a new "pipeline" serializer :

<map:generate src="another_xdoc.xml"/>
<map:serialize type="pipeline" src="doc2pdf"/>

Note : the "src" attribute doesn't currently exist on <map:serialize>, but it seems the more natural and consistent way to name the called pipeline. Wether this translates to implementing SitemapModelComponent or not is another story.

Ok, I would call this "src" but something different, but that doesn't
play a role for the concept itself.
What I don't like is that a complete pipeline is called and there
the generator is ignored. This would confuse everyone, I guess.

</snip>

Again, this looks a little bit strange that generator and serializer
have to be specified but are actually ignored. I can already hear
thousands of complains from users telling: "Why do I have to declare
them when they are not used?".

I thought of defining some "not-used" generator and serializer, if you really want to constrain a particular use of a pipeline. These would for example simply throw an exception explaining that this pipeline is not used as expected.

I haven't thought much about this, but I think if we want to define
services which can be called, than we should have a special syntax for
this, to make explicitly clear that services are defined and not
pipelines.

I personally would like to add new concepts for new things rather than to try to press them into existing concepts where they do not
fit 100%.

Mmmh... actually, the concept is new only on the called block/sitemap part. On the caller side, we just want a generator/transformer/serializer. Also, please refer to Stefano's post where he explains the usefulness of complete pipelines for testing and reuse.

It's a pitty that we didn't had time to discuss this face-to-face,
because that's a lot easier as I learned from the blocks concept...

Yep. But we discussed a lot of other topics that were also interesting. Next year, we should manage to have more time for BOFs or in-depth design sessions.

Sylvain

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




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]