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]
