Carsten Ziegeler wrote:
Ok, this all depends on what you consider configuration vs execution
information. If you look at the current Cocoon sitemap components
they've only a little configuration (everything that can be configured
in the "components" section of the sitemap). Most information is
passed in as execution information like the source to read from or any
additional paramter.
The component configuration can be easily done by a spring bean
configuration. The execution information is the interesting part as
this is different between each pipeline run.
You've seen the sitemaps and configuration we used. Often we would code
something like src="${request:bankid}/somedata.xml" in the xconf (Spring
configuration). On every execution bankid would be dynamically resolved
so that every request could be on behalf of different banks. Of course,
the ability to do this is highly dependent on the components ability (or
the sitemap's) ability to perform variable resolution. We were often
force to do something like src="cocoon://${request:bankid}/somedata.xml"
just to get around this.
Wouldn't liberal use of this concept solve the problem?
So, some pseudo code could look like this:
// read configuration of pipeline from "somewhere"
String type = // the component type
Map m = // the execution information
Transformer t = springContext.getBean(type);
t.setup(m);
Now, my configuration of the pipeline is actually stored in a JCR :)
but this is comparable with using the sitemap.xmap. Of course it
should contain a "src" information for the transformer to work.
Are you just getting the pipeline via WebDav? If so that isn't really
any different. If you are using the JCR API that could probably just be
abstracted into a JCR protocol handler.
Am I missing something?
Ralph
