Peter, I was kinda loking at this, and thinking about the pipeline.. There are actually a lot of siutations where having a pipeline is useful. Not just in request processing, but anywhere where you have a dynamic number of steps...
For instance, in a situation where you wanted to login a user you might want a pipeline that did: 1) Get data 2) Authenticate against database 3) authenticate against NT 4) Update last login 5) COnfigure session variables I think that you are on the right track, as RunData is way too specific to Turbine and the turbine enviroment. Instead, what I would like to see is a more generic PipelineData or PipelineRequest.. Not sure about Request though, as that implies a response, which we don't really have.. So maybe PipelineData or PipelineContext is best as a name? I can see the Pipeline stuff being pulled out of Turbine, and made part of fulcrum-pipeline as a standalone entity. Then, Turbine CVS has the TurbinePipelineService and the various Turbine specific valves... Since we are thinking about a pretty heavy refactoring etc, lets make sure from the outset that we have plenty of unit tests for this new code.. I spent quite a few nights writing the initial unit tests for the Turbine valves, and I think they help contribute to stability! Also, let's move this over to Turbine Dev... Let me know how I can help.. Eric > -----Original Message----- > From: Peter Courcoux [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 06, 2004 8:57 PM > To: Turbine Users ListTurbineUsersList > Subject: [Thoughts and proposal] RunData > > > Hi all, > > I have recently been working with several apps under Turbine 2.4, some > ported from Turbine 2.3 and some new. > > On 4th April I submitted a patch to the dev list allowing the adding of > objects to RunData to help with moving custom objects along the new > pipeline in turbine 2.4. > > However, the more I look at this the more I think it would be better to > have a new mechanism. > > The purpose of the pipeline is to modularise request handling and to use > pipeline valves to handle every stage of processing. This makes it very > easy to add new stages into the pipeline for custom handling. > > A couple of examples :- > > I have implemented a new valve which provides some security validation > of incoming parameters. This valve is the first in the pipeline and in > its processing it creates a ValidationResults object which is used to > assist with form redisplay and as a result is required much further down > the pipeline. > > I have also worked with a large turbine application using a workflow > engine, currently based on turbine 2.3, where, in essence, the workflow > engine decides the next screen to display. When this application is > ported to turbine 2.4, I can see that it would be very elegant to add > valves to the pipeline to handle some aspects of the interaction with > the workflow engine. > > There is therefore a general need to pass objects along the pipeline > between valves. > > Currently, each valve in the pipeline takes a RunData object as a > parameter to its invoke() method and RunData is passed along the > pipeline. However, as mentioned in my post to the dev list on 3rd April, > there is no accessible Map to allow adding objects to RunData. > > One option is to add such functionality to RunData. Easy to do and > backwards compatible. > > The other option is to create a new interface, say RequestData, with a > single purpose, that of passing objects along the pipeline. > > For backwards compatibility, RunData can be added as the first entry. It > would be trivial to extract RunData in each valve in the pipeline. This > would have the effect of making RunData available throughout the request > in exactly the way that it is now. > > public interface RequestData { > > public void putObject(String key, Object obj); > > public Object getObject(String key); > > } > > > and in the invoke method of each valve :- > > public void invoke(RequestData requestData, ValveContext valveContext) { > > RunData data = (RunData) requestData.getObject(RUNDATA); > // do whatever with data... > > invokeNext(RequestData requestData, ValveContext valveContext); > } > > > So why do it this way? RunData is a large interface with some 79 > methods, some of which are tied very closely to things like the security > service, such as getUser(), getACL() etc. It seems to me that it tries > to do too much and, over time, I would prefer to see a series of smaller > interfaces which are focused much better on single concerns. > > It will then be easier to make parts of the turbine framework pluggable. > > PROPOSAL > > 1. I am <emphasis>NOT</emphasis> suggesting doing away with RunData > anytime soon. > > 2. I am proposing creating a new RequestData interface/class with the > sole concern of passing objects along the pipeline for the life of the > request. > > 3. I am proposing that new valves make use of the RequestData object to > pass closely focused data along the pipeline. > > I am a fan of 'Separation of Concerns' and believe that this would be an > improvement to turbine and make future development more modular and > considerably easier. > > If the users and developers are in agreement with this, I would be happy > to provide patches. > > My last post on this subject to the dev list on 3rd April elicited no > response! > > Any thoughts anyone? > > Peter > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
