Henning, Eric,
On Tue, 2004-05-18 at 16:09, Henning P. Schmiedehausen wrote:
> "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);
Absolutely!
>
> 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.
>
I have to think more about listeners.
> >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.
>
Agreed.
> 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 think that in most cases TemplateInfo type objects will be created
specifically by valves (or factories called from valves), and would only
be created if needed. I'm not sure that I yet see what additional value
having listeners would give.
>
> >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...
I'm not convinced about this. I think I would tend to get what we need
working in turbine and factor it out later if it makes sense.
>
> 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
Regards,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
