Jason van Zyl <[EMAIL PROTECTED]> writes: > On 2/7/02 9:53 PM, "Daniel Rall" <[EMAIL PROTECTED]> wrote: > >> James Taylor <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] * * 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:[EMAIL PROTECTED]";>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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
