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 23:01:43 GMT
On Thu, Jul 17, 2008 at 5:27 PM, Steven Dolg <stevendolg@gmx.at> wrote:
> Peter Hunsberger schrieb:
>>

<snip/>

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

Well given that the entire discussion is abstract that's sort of hard
to answer.....  However, I sort of covered a bit of this, if Corona is
going to support non SAX pipelines they you've to assume source and
sinks that you'll want to mix and match.  In addition you can assume
multiple  types of applications, for example Servlets and Command Line
(and I'm sure others).  Whenever I see three distinct orthogonal class
dimensions like this it seems that you end up with a multitude of
constructors or initialization methods each taking a set of different
of classes. I'm basically proposing that instead we end up with a
single set of Adapter classes instead.  The exterior classes (being
adapted from)  come from  the application specific environments and
may be Servlet context, pipeline config, command line params or even
the output of other pipelines (I've got a secret agenda here).  The
interior classes (those we adapting to) are yet to be defined but are
basically going to configure the pipeline components.


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

Umm no,  I'm trying to move away from something like a Map, the
example was just  because Carsten was already using a Map and there
shoudl be no reason that the Adapter shouldn't make it easy for him to
retain most of his existing code.

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

nto sure how you figure this?  If there is a mess the adapter makes it
easier to handle, not worse, since you;'re basically converting to a
canonical form instead of having something like N X M transforms.

>
> The other thing I'm sure about:
> Why would I want to iterate over the pipeline components?

That was from the previous code as an example of pipeline
configuration (I think).  I'm guessing this is similar to Cocoon where
all the Setup methods are run for the pipelnie.

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

Yea, the implementation sketched out is part of the internal Corona
code, it's not something the client / app code should see.

Gotta run, hope that doesn't confuse things even more...

-- 
Peter Hunsberger

Mime
View raw message