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 well right now in
Turbine...
----------------------------------------------------------------------
------
Edgar Gonz�lez Gonz�lez
VALHALLA Project, s.a.
Chief Technology Officer
Web: www.valhallaproject.com
E-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
Phone: +58-212-242.4379 / 6662 / 4055 / 6475
Fax: +58-212-242.6809
"The limits of my language mean the limits of my world."
Ludwig Wittgenstein
----------------------------------------------------------------------
------
Peter Courcoux <[EMAIL PROTECTED]> wrote:
(05/06/2004 15:56)
>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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
