cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [Flow] getComponent(id) implementation
Date Fri, 27 Jun 2003 16:27:48 GMT
Carsten Ziegeler wrote:

>Geoff Howard wrote:
>>Do we want to force people to edit cocoon.xconf to call their own business
>>components from the flow?  I thought Stefano proposed checking for
>>SitemapModelComponent and disallowing it?  Would that prevent looking up
>>a transformer, but allow looking up a legitimate component defined in
>>I'm still wanting to enable people (me!) to reuse action _code_ (not the
>>contract) with little re-coding of the original class file where not
>>necessary.  If that can't be done in a clean way that doesn't invite abuse
>>then so be it, but I think it's worth trying for.
>I just listed the solution without saying if I prefer it or not; basically
>I don't know which is the best, but I tend to agree with Sylvain that
>we should not build up a unnecessary wall. Ok, we could sheck for
>SitemapModelComponent but I'm not sure if this is required.

SitemapModelComponent cannot help here, since those components 
(generators and transformers, but not serializers) are managed by a 
ComponentSelector. And this is this selector that will be looked up 
through getComponent().

So the only way to forbid access to pipeline components (but again, does 
it really make senses to use them in the flow ?) is to forbid access to 
their selectors, through their respective roles (GeneratorSelector, 
TransformerSelector, etc).


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message