cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Hunsberger" <peter.hunsber...@gmail.com>
Subject Re: [Corona] PIpeline API
Date Thu, 17 Jul 2008 15:08:06 GMT
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....

> 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) i.next();
>>    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) i.next();
      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.

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.

-- 
Peter Hunsberger

Mime
View raw message