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]
