James,
>
> <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>
I think this is an excellent approach. Only problem I can see is what if
there is no extension in the request. What if I want the result of a form
submission to my FDF. I guess I could just put something like:
action="$link.setAction(...).setPage(".FDF")"
or something like that.
> 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.
yes. yes. yes.
> 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,
No I don't like this, I would prefer to do all rendering in a target valve.
This makes more sense in the design. I guess I just need to make sure that
the relevant data in the the session.
> 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.
>
Yes I prefer this but its difficult to see how it would work:
ACTION:
1.Parse Form data
2.Put it in session?
VALVE:
1. Get data from session
2. Render appropriate FDF File
????
Not really sure about this approach. At the moment the result of the action
is a byte[] (or String actually) which represents the FDF. I could store
just this output in the session. Then print it to the output stream in the
valve. Seems like a weird way to pass data around though.
What to you think?
Gareth
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
