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]
