cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Hartmann <andr...@apache.org>
Subject Re: [Corona] PIpeline API
Date Thu, 17 Jul 2008 16:22:30 GMT
Hi Peter,

Peter Hunsberger schrieb:
> On Thu, Jul 17, 2008 at 9:22 AM, Carsten Ziegeler <cziegeler@apache.org> wrote:
>> Andreas Hartmann wrote:
> 
>>> I don't think that the calling code has to know the actual components,
>>> but rather the environment-specific interfaces of the components. It
>>> only makes sense to pass an environment to a pipeline component if the
>>> component is designed to use this environment.
> 
> Yeah, but if you've got really generic code this can be hard to figure out....

IMO there are two types of components which have to be generic:

* the pipeline implementation
* multi-purpose pipeline components

The application itself is not generic, it knows which environment 
information to provide to the application-specific components. For 
multi-purpose pipeline components (e.g., an event logger), an adapter 
class could be used (e.g., to pass an application-specific output stream 
to log the events to).

[…]

> I keep wondering if this perhaps an Adapter type pattern?  You've
> potentially got a lot of different types of applications that each
> could have different requirements for setting up pipelines.
> Similarly, you've potentially got a lot of different types of
> pipelines (in particular since Corona isn't just SAX).   So what you
> do is define some adapter that gets passed around and leave it up to
> the adapter to manage the use case specifics,
> 
> Adaper adp = new MyUseCaseAdapter();
> adp.setRequest(  req );
>    .
>    .
>    .
>   for (Iterator i = pipeline.getComponents().iterator(); … ) {
>     PipelineComponent c = (PipelineComponent) i.next();
>       c.setup(adp);
>     }

I'm not quite sure what c.setup() would look like. Perhaps like this?

class XsltTransformer {
   public void setup(Adapter adp) {
     setXsltParams(adp.getXsltParams());
   }
}

In this case, the Adapter implementation would have to provide methods 
for various types of pipeline components …

> And then in the component:
> 
> Object myConfigParam = adp.getParam( NAME );

But wouldn't this require a contract between the application and the 
components based on parameter names? I thought this is what we wanted to 
avoid, otherwise we could just use the Map suggested by Carsten …

But I guess I'm misunderstanding something :)

> has no knowledge of how the param (or params) was passed into the adapter.
> 
> The app is responsible for setting up the adapter with app specific
> data and the adapter has multiple standard methods for allowing this
> (and can be extended for new use cases).  The adapter is responsible
> for passing it into the components in some more standardized way.
> Think of the adapter as a data class with extra logic for converting
> use case specific data into generic data.

Hmm, what does the term "generic data" refer to? Would you mind giving 
an example? TIA!

> As such, the adapter can also be responsible for more than
> initialization data, it can become the use case specific way of
> communicating between the app and the components.  Instead of using
> marker interfaces to define the use case specific responsibilities you
> end up with the adapter having multiple methods for different use
> cases as needed.

As I understand it, one would have to provide application-specific 
adapters to "environmentalize" multi-purpose components; I don't see a 
way how this could be handled by a single adapter class for the whole 
application …

I'll think a bit more about this, sorry if my remarks are rubbish :)

-- Andreas


-- 
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01


Mime
View raw message