On Thu, Jul 17, 2008 at 5:27 PM, Steven Dolg <[EMAIL PROTECTED]> 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
