Eric, I have completed patches for the proposed change to RequestData. I have taken the opportunity to update to the Apache 2 licence in all the pipeline package files.
Before submitting these, do you know what the jakarta regime is following the recommendations to remove @author tags. Should this be done for turbine? So far I have tried to follow the jakarta coding style as set out on the web page. Regards, Peter On Sat, 2004-05-08 at 14:19, Eric Pugh wrote: > Definitly, if you are submitting patches, send them to the dev list. The > traffic on the user list means that patches are sometimes lost. > > We are working on getting more committers for Turbine, with Jeff Painter as > the latest, so we hope to address this issue. > > Definitly, keep the patches and enhancements coming, and as people > demonstrate interest and committment, we'll be adding them. > > Eric Pugh > > > -----Original Message----- > > From: Aníbal Rojas [mailto:[EMAIL PROTECTED] > > Sent: Friday, May 07, 2004 3:02 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [Thoughts and proposal] RunData > > > > > > Hi Peter, > > > > +1 > > > > This sound like a "cleaner" approach. > > > > BTW, there have been a few patches submitted by different people > > to the dev > > & user lists, which lacked response from the committers. > > I guess the OpenSource projects "live" from the users contribution, but I > > looks like this mechanism isn't working smoothly now in Turbine... > > > > Aníbal Rojas > > [EMAIL PROTECTED] > > 58+212+242.66.62 / 43.79 > > Fax: 58+212+243.68.09 > > > > > Subject: [Thoughts and proposal] RunData > > > From: Peter Courcoux <[EMAIL PROTECTED]> > > > Content-Type: text/plain > > > Date: Thu, 06 May 2004 20:56:32 +0100 > > > > > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
