cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <>
Subject Re: [Corona] PIpeline API
Date Thu, 17 Jul 2008 22:27:22 GMT
Peter Hunsberger schrieb:
> On Thu, Jul 17, 2008 at 9:22 AM, Carsten Ziegeler <> 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....
>> Agreed.
>>> Maybe I can try to come
>>> up with a more generic example:
>>> public interface WebappPipelineComponent extends PipelineComponent {
>>>  void setRequest(Request request);
>>> }
>>> Client code inside a web application:
>>> public void parameterizeComponents(Request req, Pipeline pipeline) {
>>>  for (Iterator i = pipeline.getComponents().iterator(); … ) {
>>>    PipelineComponent c = (PipelineComponent);
>>>    if (c instanceof WebappPipelineComponent) {
>>>      WebappPipelineComponent wpc = (…) c;
>>>      wpc.setRequest(req);
>>>    }
>>>  }
>>> }
>>> The pipeline is executed in a specific environment. The actual
>>> pipeline object itself is oblivious of the environment information, but
>>> the pipeline components are directly dependent on the environment.
>> Hmm, yes this would work, but :) this would make it harder to have a
>> reusable pipeline implementation that frees my application from passing the
>> information to the components.
>> Currently the app creates a map, passed it to the pipeline implementation
>> and this implementation passes the map on to the components.
>> With the approach above, I would need a custom pipeline implementation to do
>> this. Furthermore there might be a lot of marker interfaces to test.
>> Actually I'm not sure which approach is nicer :)
> 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);
>       c.setup(adp);
>     }
> And then in the component:
> Object myConfigParam = adp.getParam( NAME );
> has no knowledge of how the param (or params) was passed into the adapter.
AFAIK an adapter is used to adapt one interface or class to another.
So what does the adapter adapt - what's the adapted class/interface?

Since c.setup(adp) belongs to the general PipelineComponent, the 
MyUseCaseAdapter has to be passed as Adapter (exactly as described above).
So this way providing parameters might become easier, but IMO reading 
parameters (inside the component) is just the same as using a map (also 
exactly as described above).
Except you want to go for a downcast... ;-)

Furthermore MyUseCaseAdapter would have to account for every possible 
configuration requirement of every component that might be in the pipeline.
This could be become quite messy if the pipeline is assembled dynamically.

The other thing I'm sure about:
Why would I want to iterate over the pipeline components?
Somehow I think it should not be necessary that client (or sitemap) code 
directly accesses the components of a pipeline after it is assembled.
That's also the reason, why there is no method to expose the components 
on the pipeline interface.

The Law of Demeter is surely something to argue about, but IMO it is 
usually better to follow it - unless you have a good reason, which I 
fail to see here.

> 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.
> 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.

View raw message