cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Using pipeline as sitemap components (long)
Date Sat, 23 Nov 2002 21:46:59 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message