Gareth's message got me thinking about handling multiple pipelines. I
know Jason is planning on adding some code to select one of a set of
pipelines based on a request parameter. I think we all agree that this
is only a temporary solution, more flexibility will be required.
So I decided to take a look at how things are implemented in cocoon and
stuts. I got scared away from struts pretty quickly, I didn't have the
patience to figure out the action mapping thing, but if anyone who uses
struts can share the advantages of that solution I'd be very interested.
Cocoon on the other hand was quite a bit easier to understand, and I
really like some aspects of their pipeline handling. Specifically
'selectors' and 'matchers' which allow user defined classes to make
decisions about the progress of the pipeline. Consider:
<pipeline>
<name>TurbineClassicPipeline</name>
<valves>
<valve className="org.jamestaylor.myapp.pipeline.DetermineTargetValve"/>
<valve className="org.jamestaylor.myapp.pipeline.RunModulesValve"/>
<select className="org.jamestaylor.myapp.pipeline.TargetExtensionSelector">
<when test="vm">
<valve className="org.jamestaylor.myapp.pipeline.DirectVelocityRendererValve"/>
</when>
<when test="jsp">
<valve className="org.jamestaylor.myapp.pipeline.JSPRendererValve"/>
</when>
<when test="swt">
<valve className="org.jamestaylor.myapp.pipeline.JGenRendererValve"/>
</when>
</select>
</valves>
</pipeline>
In this case we have a selector that parses the extension of the target
and selects the appropriate renderer. One important thing is that the
parsing of the target is done AFTER RunModulesValve, so if a module
changes the target, it will go to the correct renderer.
This gives users a ton of flexibility. We could implement some standard
selectors, for example ones that look at request parameters or objects
stored in RunData (however that looks when Jason finishes with it). The
base classes for selectors could be more intelligent, to allow globbed
or regexp matches.
In Gareth's case, this would allow him a few ways to accomplish his
goal. He could simply leave out any target valve for certain extensions,
or have a matcher that ignores that valve if the output stream is
already opened. Or (the one I prefer) he could implement a valve for
rendering using the FDF sdk, and use a selector to ensure that that
valve is run for the relevent targets.
Thoughts?
Thanks, jt
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
