> Definitely cool, but I would like to leave the conditional aspects as > optional so that in the case where you have an application that is using a > single view type is optimized.
I agree, and a solution like this gives total flexibility. If you want to just have a straight pipeline you don't use any conditional valves. If you want more complicated conditional selection you can use the conditional valves (and selector valves once built) to accomplish almost anything. They can be nested without theoretical limit. > I think your valves would also be very > valuable for people migrating apps from jsp to velocity (no one would ever > go the other way!) Or using both at the same time. Which I agree is unlikely, but there are other things that fit into this model that people might want to be able to use concurrently, like vm, image generation with batik, pdf with fop (or the fdf sdk that several people seem to need, whatever it is), flash content with JGen. > Does the pipeline you whipped up make jsp work with the classic model? That > would be very cool if it does! Yup! Well, no layouts, but the standard action - module - template chaining model should work. The archive I sent you privately has a config in src/rttest/conf/turbine-testapp-pipeline.xml that should support the classic model for vm, jsp, and set with selection based on the extension, although I believe it leaves out RunModulesValve for jsp since I was emulating the other jsp pipeline. > John and I also briefly discussed a top-level selector, as I agreed with him > when said he didn't like the idea of being able to select a pipeline with > parameters. It would also be nice to be able to avoid the selector as well > for say a pure velocity app so we can make things as optimal as possible. Totally. I think doing the selectors with valves is the way to go since you get full flexibility. You can have a selector at the top (top level pipeline with one selector valve containing other pipelines that get executed conditionally), Just a standard pipeline (no conditional or selection valves at all), or any more complicated flow. The mapper makes the easy because we can pass arbitrary implementation specific parameters (in the form of bean properties) to the valves for configuration. Thus people can subclass the BaseConditionalValve (and BaseSelectorValve or whatever we end up with for that) and configure it however they want in the pipeline xml file. -- jt -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
