OK, I've thought more about the problem. What we need is a way to send data from the action valve to the target value.
The session (which was my first suggestion) is a terrible work around. We should never rely on a session being there in the pipeline. So I once again suggest that we modify the runData. This seems to be the only sensible way of sending data from valve to valve. The idea is : In your action, you create some raw data (pdf, images). You then call data.setRawData(data, contentType) This will create a reference to the raw data in the runData and also call data.setContentType(). Then you set up a new target (using James suggested extension based configuration) which will do the follwing: data.getResponse().setContentType(data.getContentType); data.getResponse().getOutputStream().write(data.getRawData()); Something like that anyway! OK - this adds another property to the runData but I think that it does provide more flexibility. Gareth > -----Original Message----- > From: Gareth Coltman [mailto:[EMAIL PROTECTED]] > Sent: 01 February 2002 16:35 > To: Turbine Developers List > Subject: RE: Thinking about 'multiple' pipeline (was Re: Possible patch > to allowfiles to be streamed back from action) > > > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
