"Eric Pugh" <[EMAIL PROTECTED]> writes:
>Thinking about what Henning wrote, I pretty much agree. RunData has way too
>much in it, and a replacement would be better..
>RunData data = ((TurbinePipelineData)myPipelineDataObject).getRunData();
What additional fields do you expect in the Turbine specific object? I'd
very much prefer doing
TemplateInfo ti = (TemplateInfo)
myPipelineDataObject.getAttribute(TemplateService.TEMPLATE_INFO);
and just pass the "myPipelineDataObject" around as the opaque data
container that has putAttribute and getAttribute methods (and probably
hasAttribute and I'd love to have some listeners on it) but that's
all.
>or alternatively, why can't RunData extend PipelineData?
Why should it?
Doing this:
public interface TurbineRunData extends PipelineData {
{
TemplateInfo getTemplateInfo();
}
with
public class TurbineRunDataImpl extends AbstractPipelineData {
{
public TemplateInfo getTemplateInfo()
{
return (TemplateInfo) getAttribute(TemplateService.TEMPLATE_INFO);
}
}
just to get rid of some typing work IMHO buys you nothing and just
makes our interfaces overloaded with lots and lots of functions.
What I'd like to see is some sort of Listener pattern, where the
TemplateInfo factory can register itself with the PipelineData Factory
and whenever a new PipelineData object is needed, the TemplateInfo
factory gets triggered and automagically adds the TemplateInfo object
to the PipelineData. Same for destruction. And when there is no Templating
registered with the core, then no templating objects are created.
>I really want to see the Pipeline be usable outside of a servlet
>request/response cycle.. There are lots of places where a pipeline of
>actions can be usefull...
One of the possible dangers IMHO is the over-generalization. At some
point we might either build real high level components like a generic
pipeline to shuffle stuff around. But then again, there is a perfectly
fine (? don't know, didn't actually look at the code) pipeline
implementation in Tomcat. The question might be, what scope the
Turbine core should have in the end? Do we end up with Plexus, just
being a really thin, generic request-response processor running a
pipeline with components or should it keep some of the "unique turbine
flavours"?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honourable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
