RE: Thinking about 'multiple' pipeline (was Re: Possible patch to allowfiles to be streamed back from action)

[James Taylor <jt...@4lane.com>]

> 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.

No, you would just use a different implementation of selector, or write
your own which parses some relevent parameter from somewhere and decides
what valve to use based on it. In cocoon the base selectors are browser,
header, host, request parameter, request attribute, session attribute.
We could implement similar selectors based on more turbine relevent
stuff.

Cocoon matchers:
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoon/matching/

Cocoon selectors:
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoon/selection/

> 
> > 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

This is the one I like since it follows the current turbine pattern.
Actions and Modules build contexts, renderer render views. In this case
you don't have a template at all, but you still have an FDFRendererValve
or whatever.

> ????
> 
> 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?

I think you have a special case where its going to be hard to make the
FDF sdk fit cleanly into the turbine model. However if we implement
something like what is described above, it would give you enough
flexibility to accomplish what you want in several ways, even if none of
them is ideal. 

Thanks,
James


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>