Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 23061 invoked by uid 500); 27 Jun 2003 16:27:47 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 23041 invoked from network); 27 Jun 2003 16:27:46 -0000 Received: from unknown (HELO trinity.anyware-tech.com) (217.112.237.100) by daedalus.apache.org with SMTP; 27 Jun 2003 16:27:46 -0000 Received: (qmail 29535 invoked from network); 27 Jun 2003 16:30:06 -0000 Received: from unknown (HELO anyware-tech.com) (10.1.0.254) by trinity.anyware-tech.com with SMTP; 27 Jun 2003 16:30:06 -0000 Message-ID: <3EFC7084.1090604@anyware-tech.com> Date: Fri, 27 Jun 2003 18:27:48 +0200 From: Sylvain Wallez Organization: Anyware Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: fr, en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [Flow] getComponent(id) implementation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 >>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 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 -- 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