From dev-return-99750-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Wed Jul 16 15:58:48 2008 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 91833 invoked from network); 16 Jul 2008 15:58:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Jul 2008 15:58:48 -0000 Received: (qmail 89514 invoked by uid 500); 16 Jul 2008 15:58:47 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 89439 invoked by uid 500); 16 Jul 2008 15:58:47 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 89428 invoked by uid 99); 16 Jul 2008 15:58:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jul 2008 08:58:46 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of stevendolg@gmx.at designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 16 Jul 2008 15:57:53 +0000 Received: (qmail invoked by alias); 16 Jul 2008 15:58:16 -0000 Received: from pluto.systemone.at (EHLO [192.168.20.53]) [85.124.93.178] by mail.gmx.net (mp066) with SMTP; 16 Jul 2008 17:58:16 +0200 X-Authenticated: #30352116 X-Provags-ID: V01U2FsdGVkX1/sE781V5XsfwPt0qvIujEAB9zv3aZUWZxrWpXb8i /CXKTUqgUqDcch Message-ID: <487E1A99.50003@gmx.at> Date: Wed, 16 Jul 2008 17:58:17 +0200 From: Steven Dolg User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [Corona] PIpeline API References: <48775DFE.7020903@apache.org> <487A10D8.3050908@apache.org> <487B03F4.8050901@apache.org> <487B1E49.5050008@apache.org> <487C7B91.2040306@apache.org> <487C7F12.2070101@apache.org> <487CD15E.5090809@apache.org> <487DE613.60208@apache.org> <487E0355.8010803@apache.org> <487E12B6.2050807@apache.org> In-Reply-To: <487E12B6.2050807@apache.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 X-Virus-Checked: Checked by ClamAV on apache.org Carsten Ziegeler schrieb: > Andreas Hartmann schrieb: >> Carsten Ziegeler schrieb: >>> Bertrand Delacretaz wrote: >>>> On Wed, Jul 16, 2008 at 5:14 AM, Sylvain Wallez >>>> wrote: >>>> >>>>> ...Can't we just give the parameters they need >>>>> individually to every pipeline component, thus allowing per-component >>>>> strongly typed and well defined contracts?.. >>>> >>>> I'm also catching up on this thread but I tend to agree with the above >>>> suggestion, i.e. something like >>>> >>>> Transformer t = new XsltTransformer(); >>>> t.setXslt("cocoon:/mytransform.xsl"); >>>> t.setRequestParameters(request.getParameterMap()); >>>> ... >>>> >>> Ok, in this case you can't use "Transformer" as the class type. This >>> would be: >>> XsltTransformer t = ... >>> >>> Now, it seems that we are still mixing up things here. As I said, >>> I'm not talking about configuration of the components. The >>> stylesheet from above is a configuration. >>> We're talking about information about the current environment for >>> executing the already configured pipeline. >> >> IIUC the request parameters in the above example would belong to the >> execution environment, wouldn't they? >> >> I'd imagine something like this: >> >> public void parameterizeTransformers(Request req, Pipeline pipeline) { >> for (Iterator i = pipeline.getTransformers().iterator(); … ) { >> Transformer t = (Transformer) i.next(); >> if (t instanceof WebappXsltTransformer) { >> WebappXsltTransformer xsltTr = (WebappXsltTransformer) t; >> if (xsltTr.useRequestParameters()) { >> xsltTr.setXsltParams(req.getParameterMap()); >> } >> } >> } >> } >> > Now all these examples assume that the calling code knows the components. > For my use case - and it's the same with the Cocoon sitemap - I've a > description of a pipeline (think of the sitemap) which has just the name > of the pipeline components to chain. A generic code instantiates these > pipeline components - through a service registry - and does not know > anything about these components apart from the fact that they are > pipeline components. I completely agree here. Specific situations might allow specific solutions, e.g. providing listeners/callbacks while creating the individual components. However a more general solution that also supports more general scenarios like the one described above (components are created by a service/factory/etc.) should also be available. I wouldn't mind having a general purpose setup/teardown (or preExecution/postExecution, etc.) method defined and called by the pipeline API itself. Might not be a good example, but JUnit provides such methods for unit tests and does not delegate this to another framework/container that might or might not be available, since this is a genuine requirement for certain tasks to be solved with the framework. However the listener approach also appears to be appealing to me. Although I'm not entirely sure this would be as easy to use as the lifecycle methods proposed before (especially when a pipeline is built by the sitemap engine or service/factory). Steven > > Carsten >