Geoff Howard wrote:
I just listed the solution without saying if I prefer it or not; basicallyDo 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 map:components?
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 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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
