Hi Peter,
Peter Hunsberger schrieb:
On Thu, Jul 17, 2008 at 9:22 AM, Carsten Ziegeler <[EMAIL PROTECTED]> 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
