You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Daniel Rall <dl...@finemaltcoding.com> on 2002/02/08 03:53:13 UTC
Re: Thinking about 'multiple' pipeline (was Re: Possible patch to allow files to be streamed back from action)
James Taylor <jt...@4lane.com> writes:
> Consider:
>
> <pipeline>
> <name>TurbineClassicPipeline</name>
> <valves>
> <valve className="org.jamestaylor.myapp.pipeline.DetermineTargetValve"/>
> <valve className="org.jamestaylor.myapp.pipeline.RunModulesValve"/>
> <select className="org.jamestaylor.myapp.pipeline.TargetExtensionSelector">
> <when test="vm">
> <valve className="org.jamestaylor.myapp.pipeline.DirectVelocityRendererValve"/>
> </when>
> <when test="jsp">
> <valve className="org.jamestaylor.myapp.pipeline.JSPRendererValve"/>
> </when>
> <when test="swt">
> <valve className="org.jamestaylor.myapp.pipeline.JGenRendererValve"/>
> </when>
> </select>
> </valves>
> </pipeline>
I need to read this more thoroughly, but after a first pass, I am
strongly -1 on this change. No programming in XML. Period.
Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/11/02 1:30 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@zenplex.com> writes:
>
>> It's good that you actually discussed the idea with James, but the reason I
>> prodded was more of a policy issue. Are we all to practice the philosophy of
>> preventing documentation being issued on methodologies we don't agree with?
>>
>> What one person views as a best practice is often not entirely congruent
>> with what another views as a best practice.
>>
>> I'm an ardent believer that actions, and flow in general, should not be
>> accessible from templates but it's a practice that exists and a methodology
>> that certainly is documented. You tried to provide a alternative to James'
>> first proposal whereas I haven't provided an alternative to the control flow
>> in templates but when I have do you think it would be a fair position for me
>> to try and prevent $link.setAction(x) from showing up in the documentation?
>>
>> I certainly think that would be a bit heavy handed.
>>
>> If someone wants to put immense quantities of logic in their templates, or
>> someone wants put logical indicators in their pipeline descriptors then so
>> be it. If they want to document it and people use it to get a job done how
>> can documentation hurt? And how would preventing documentation on a
>> particular methodology, even if highly disliked by certain parties, help
>> anyone?
>
> You make good points. I wouldn't be adverse to documentation and
> publish of controversial material so large as it wasn't positioned by
> the rest of the documentation as the One True Way -- because as you
> point out, the way is different for everyone.
That's exactly my point. Precluding methodologies based on personal opinion
seems rather arbitrary and, really, in Turbine there has never been any One
True Way to do anything. Not yet anyway.
>
> Dan
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
> It's good that you actually discussed the idea with James, but the reason I
> prodded was more of a policy issue. Are we all to practice the philosophy of
> preventing documentation being issued on methodologies we don't agree with?
>
> What one person views as a best practice is often not entirely congruent
> with what another views as a best practice.
>
> I'm an ardent believer that actions, and flow in general, should not be
> accessible from templates but it's a practice that exists and a methodology
> that certainly is documented. You tried to provide a alternative to James'
> first proposal whereas I haven't provided an alternative to the control flow
> in templates but when I have do you think it would be a fair position for me
> to try and prevent $link.setAction(x) from showing up in the documentation?
>
> I certainly think that would be a bit heavy handed.
>
> If someone wants to put immense quantities of logic in their templates, or
> someone wants put logical indicators in their pipeline descriptors then so
> be it. If they want to document it and people use it to get a job done how
> can documentation hurt? And how would preventing documentation on a
> particular methodology, even if highly disliked by certain parties, help
> anyone?
You make good points. I wouldn't be adverse to documentation and
publish of controversial material so large as it wasn't positioned by
the rest of the documentation as the One True Way -- because as you
point out, the way is different for everyone.
Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/11/02 4:57 AM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@zenplex.com> writes:
>
>> On 2/9/02 1:49 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
>>
>>> First off, let me say that I am not against the idea of a "selector"
>>> for multiple pipelines. It's just the suggested implementation that I
>>> have issues with.
>>>
>>> Even though I don't think that even optional pipeline capabilities
>>> should be programmable from XML, I will not -1 its inclusion (on an
>>> optional basis). However, I will not support promotion of such
>>> facilities in the Turbine documentation
>>
>> What does that mean exactly? You won't write documentation yourself
>> promoting this method, or that you will prevent someone else from doing it.
>>> From the tone it sounds like the latter.
>
> The latter. But after talking with James on IRC, it looks like our
> ideas are actually much closer than I had first thought, so much so
> that I was able to take his base Valve and easily subclass it from my
> branch point suggestion.
It's good that you actually discussed the idea with James, but the reason I
prodded was more of a policy issue. Are we all to practice the philosophy of
preventing documentation being issued on methodologies we don't agree with?
What one person views as a best practice is often not entirely congruent
with what another views as a best practice.
I'm an ardent believer that actions, and flow in general, should not be
accessible from templates but it's a practice that exists and a methodology
that certainly is documented. You tried to provide a alternative to James'
first proposal whereas I haven't provided an alternative to the control flow
in templates but when I have do you think it would be a fair position for me
to try and prevent $link.setAction(x) from showing up in the documentation?
I certainly think that would be a bit heavy handed.
If someone wants to put immense quantities of logic in their templates, or
someone wants put logical indicators in their pipeline descriptors then so
be it. If they want to document it and people use it to get a job done how
can documentation hurt? And how would preventing documentation on a
particular methodology, even if highly disliked by certain parties, help
anyone?
> Dan
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
> On 2/9/02 1:49 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
>
>> First off, let me say that I am not against the idea of a "selector"
>> for multiple pipelines. It's just the suggested implementation that I
>> have issues with.
>>
>> Even though I don't think that even optional pipeline capabilities
>> should be programmable from XML, I will not -1 its inclusion (on an
>> optional basis). However, I will not support promotion of such
>> facilities in the Turbine documentation
>
> What does that mean exactly? You won't write documentation yourself
> promoting this method, or that you will prevent someone else from doing it.
> >From the tone it sounds like the latter.
The latter. But after talking with James on IRC, it looks like our
ideas are actually much closer than I had first thought, so much so
that I was able to take his base Valve and easily subclass it from my
branch point suggestion.
Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/9/02 1:49 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> First off, let me say that I am not against the idea of a "selector"
> for multiple pipelines. It's just the suggested implementation that I
> have issues with.
>
> Even though I don't think that even optional pipeline capabilities
> should be programmable from XML, I will not -1 its inclusion (on an
> optional basis). However, I will not support promotion of such
> facilities in the Turbine documentation
What does that mean exactly? You won't write documentation yourself
promoting this method, or that you will prevent someone else from doing it.
>From the tone it sounds like the latter.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
> On 2/7/02 9:53 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
>
>> James Taylor <jt...@4lane.com> writes:
>>
>>> Consider:
>>>
>>> <pipeline>
>>> <name>TurbineClassicPipeline</name>
>>> <valves>
>>> <valve className="org.jamestaylor.myapp.pipeline.DetermineTargetValve"/>
>>> <valve className="org.jamestaylor.myapp.pipeline.RunModulesValve"/>
>>> <select
>>> className="org.jamestaylor.myapp.pipeline.TargetExtensionSelector">
>>> <when test="vm">
>>> <valve
>>> className="org.jamestaylor.myapp.pipeline.DirectVelocityRendererValve"/>
>>> </when>
>>> <when test="jsp">
>>> <valve className="org.jamestaylor.myapp.pipeline.JSPRendererValve"/>
>>> </when>
>>> <when test="swt">
>>> <valve className="org.jamestaylor.myapp.pipeline.JGenRendererValve"/>
>>> </when>
>>> </select>
>>> </valves>
>>> </pipeline>
>>
>> I need to read this more thoroughly, but after a first pass, I am
>> strongly -1 on this change. No programming in XML. Period.
>
> I was chatting with James about this and I don't feel this would be the
> standard pipeline that we ship but what's above is completely optional and
> provides one form of a selector mechanism. What's there is just another
> valve.
>
> Again, I'm not that keen on this being the default but we will need a
> selector mechanism and this is just one option. All the logic is contained
> in a valve and doesn't hurt anything else.
First off, let me say that I am not against the idea of a "selector"
for multiple pipelines. It's just the suggested implementation that I
have issues with.
XML is a data markup language (see point of of the W3C's XML FAQ at
http://www.w3.org/XML/1999/XML-in-10-points), not a programming
language -- trying to do any sort of programming in XML is a Bad Idea
(I would use Ant as an example of how bad an idea this is, but I have
a feeling that some of you would actually use Ant as a templar
supporting this insanity ;-P ).
Even though I don't think that even optional pipeline capabilities
should be programmable from XML, I will not -1 its inclusion (on an
optional basis). However, I will not support promotion of such
facilities in the Turbine documentation, as it is most definitely not
a best practice.
Java is for programming, and Valves are for Pipeline control. The
Right Way of handling pipeline selection is to implement a Valve which
encapsulates your selection rules, and configure any inputs to this
selector mechanism via your XML descriptor. This keeps flow control
out of the XML (where it doesn't belong), and in the Java code (which
is best suited to dealing with such things). I've attached just such
a selector mechanism, the BranchPoint class (a Valve implementation),
which I propose is used to solve this problem. Just attach a
BranchPoint subclass (which implements the chooseBranch() method) near
the beginning of your pipeline, and you'll have support for multiple
pipelines.
It all comes down to using the right tool for the job.
Comments and criticisms welcome.
Thanks, Dan
package org.apache.turbine.pipeline;
/* ====================================================================
* The Apache Software License, Version 1.1
*
* Copyright (c) 2001 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. The end-user documentation included with the redistribution,
* if any, must include the following acknowledgment:
* "This product includes software developed by the
* Apache Software Foundation (http://www.apache.org/)."
* Alternately, this acknowledgment may appear in the software itself,
* if and wherever such third-party acknowledgments normally appear.
*
* 4. The names "Apache" and "Apache Software Foundation" and
* "Apache Turbine" must not be used to endorse or promote products
* derived from this software without prior written permission. For
* written permission, please contact apache@apache.org.
*
* 5. Products derived from this software may not be called "Apache",
* "Apache Turbine", nor may "Apache" appear in their name, without
* prior written permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
* ====================================================================
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* <http://www.apache.org/>.
*/
import java.io.IOException;
import org.apache.turbine.RunData;
import org.apache.turbine.TurbineException;
import org.apache.turbine.Valve;
import org.apache.turbine.ValveContext;
/**
* A {@link org.apache.turbine.Valve} description of a pipeline's
* branch point. May itself be the start of zero or more {@link
* org.apache.turbine.Pipeline} paths.
*
* @author <a href="mailto:dlr@finemaltcoding.com">Daniel Rall</a>
* @version $Id: DefaultActionValve.java,v 1.7 2002/01/24 03:55:26 jvanzyl Exp $
*/
public abstract class BranchPoint
extends AbstractValve
{
/**
* Calls <code>chooseBranch()</code> to pick a pipeline path.
*
* @see #chooseBranch(RunData, ValveContext)
* @see org.apache.turbine.Valve#invoke(RunData, ValveContext)
*/
public void invoke(RunData data, ValveContext context)
throws IOException, TurbineException
{
try
{
chooseBranch(data, context);
}
catch (Exception e)
{
throw new TurbineException(e);
}
}
/**
* <p>Selects which pipeline path to branch down. This may just
* consist of calling <code>context.invokeNext(data)</code> to
* continue down the current pipeline's path. The desired branch
* path is generally determined using data pulled from the
* supplied<code>RunData</code>.</p>
*
* <p>Here's an illustration of inserting a
* <code>BranchPoint</code> into the <code>TurbinePipeline</code>
* processing sequence:
*
* <blockquote><pre>
* ___ (start of FooPipeline)
* /
* ---[Valve]--[Valve]--[BranchPoint]---- (continue w/ TurbinePipeline)
* \
* --- (start of BarPipeline)
* </pre></blockquote>
*
* The <code>BranchPoint</code> could just as easily stop all
* processing by neither invoking a new pipeline nor calling
* <code>invokeNext()</code>.
* </p>
*
* @param data The run-time data.
* @exception Exception Problem choosing pipline to branch down.
*/
protected abstract void chooseBranch(RunData data, ValveContext context)
throws Exception;
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thinking about 'multiple' pipeline (was Re: Possible patch to
allow files to be streamed back from action)
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/7/02 9:53 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> James Taylor <jt...@4lane.com> writes:
>
>> Consider:
>>
>> <pipeline>
>> <name>TurbineClassicPipeline</name>
>> <valves>
>> <valve className="org.jamestaylor.myapp.pipeline.DetermineTargetValve"/>
>> <valve className="org.jamestaylor.myapp.pipeline.RunModulesValve"/>
>> <select
>> className="org.jamestaylor.myapp.pipeline.TargetExtensionSelector">
>> <when test="vm">
>> <valve
>> className="org.jamestaylor.myapp.pipeline.DirectVelocityRendererValve"/>
>> </when>
>> <when test="jsp">
>> <valve className="org.jamestaylor.myapp.pipeline.JSPRendererValve"/>
>> </when>
>> <when test="swt">
>> <valve className="org.jamestaylor.myapp.pipeline.JGenRendererValve"/>
>> </when>
>> </select>
>> </valves>
>> </pipeline>
>
> I need to read this more thoroughly, but after a first pass, I am
> strongly -1 on this change. No programming in XML. Period.
I was chatting with James about this and I don't feel this would be the
standard pipeline that we ship but what's above is completely optional and
provides one form of a selector mechanism. What's there is just another
valve.
Again, I'm not that keen on this being the default but we will need a
selector mechanism and this is just one option. All the logic is contained
in a valve and doesn't hurt anything else.
> Dan
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>