cocoon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ovi...@apache.org
Subject cvs commit: xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/components/flow Interpreter.java
Date Wed, 13 Mar 2002 18:52:57 GMT
ovidiu      02/03/13 10:52:57

  Added:       src/scratchpad/schecoon/src/org/apache/cocoon/components/flow
                        Interpreter.java
  Log:
  Provides the interface between Cocoon and a scripting engine used for
  the flow control.
  
  Revision  Changes    Path
  1.1                  xml-cocoon2/src/scratchpad/schecoon/src/org/apache/cocoon/components/flow/Interpreter.java
  
  Index: Interpreter.java
  ===================================================================
  package org.apache.cocoon.components.flow;
  
  import java.io.Reader;
  import java.util.HashMap;
  import org.apache.avalon.framework.parameters.Parameters;
  import org.apache.avalon.framework.thread.ThreadSafe;
  import org.apache.cocoon.components.treeprocessor.InvokeContext;
  import org.apache.cocoon.environment.Environment;
  
  /**
   * The interface to the flow scripting languages. This interface is
   * for a component, which implements the appropriate language to be
   * used for describing the flow. A system could have multiple
   * components that implement this interface, each of them for a
   * different scripting language.
   *
   * <p>A flow script defines what is the page flow in an interactive
   * Web application. Usually the flow is defined in a high level
   * programming language which provides the notion of continuations,
   * which allows for the flow of the application to be described as a
   * simple procedural program, without having to think about the
   * application as a finite state machine which changes its internal
   * state on each HTTP request from the client browser.
   *
   * <p>However an implementation may choose to use its own
   * representation of an application, which may include XML
   * representations of finite state machines. Note: this API has no
   * provision for such implementations.
   *
   * <p>The component represented by this interface is called in three
   * situations:
   *
   * <ul>
   *
   *  <li>
   *
   *    <p>From the sitemap, to invoke a top level function defined in a
   *    * given implementation language of the flow. This is done from
   *    the * sitemap using the construction:
   *
   *    <pre>
   *      &lt;map:call function="..." language="..."/&gt;
   *    </pre>
   *
   *    <p>The <code>language</code> attribute can be ignored if the *
   *    default language is used.
   *
   *  <li>
   *
   *    <p>From the sitemap, to continue a previously started
   *    computation. A previously started computation is saved in the
   *    form of a continuation inside the flow implementation language.
   *
   *    <p>This case is similar with the above one, but the function
   *    invoked has a special name, specific to each language
   *    implementation. See the language implementation for more
   *    information on the function name and the arguments it receives.
   *
   *  <li>
   *
   *    <p>From a program in the flow layer. This is done to invoke a
   *    pipeline defined in the sitemap, to generate the response of the
   *    request.
   *
   * </ul>
   *
   * @author <a href="mailto:ovidiu@cup.hp.com">Ovidiu Predescu</a>
   * @since March 11, 2002
   * @see InterpreterSelector
   */
  public interface Interpreter
  {
    public static String ROLE = "org.apache.cocoon.components.flow.Interpreter";
  
    /**
     * Load a script from Reader.
     *
     * @param in a <code>Reader</code> value
     */
    void readScript(Reader in)
      throws Exception;
  
    /**
     * This method is called from the sitemap, using the syntax
     *
     * <pre>
     *   &lt;map:call function="..."/&gt;
     * </pre>
     *
     * The method will execute the named function, which must be defined
     * in the given language. There is no assumption made on how various
     * arguments are passed to the function. A particular language
     * implementation may decide to put the environment, request,
     * response etc. objects in the dynamic scope available to the
     * function at the time of the call. Other implementations may
     * decide to pass these as arguments to the called function.
     *
     * <p>The current implementation assumes the sitemap implementation
     * is TreeProcessor.
     *
     * @param funName a <code>String</code> value, the name of the
     * function to call
     * @param params a <code>Parameters</code> value, parameters to pass
     * to the function. The interpretation of the parameters is left
     * @param env an <code>Environment</code> value
     * @param ctx an <code>InvokeContext</code> value
     */
    void callFunction(String funName, Parameters params,
                      Environment env, InvokeContext ctx)
      throws Exception;
  
    /**
     * Process a named pipeline defined using
     * <code>&lt;map:resource/&gt;</code> in the sitemap.
     *
     * @param name a <code>String</code> value, the name of the pipeline
     * (resource) in the sitemap.
     * @param pipelineArgs a <code>HashMap</code> value, the arguments
     * to be passed to the sitemap.
     * @param bizData a <code>Object</code> value, the Java object or
     * <code>null</code> which contains the business data to be passed
     * to the generator of the pipeline (usually XSP or JSP).
     */
    void processPipeline(String name, HashMap pipelineArgs, Object bizData)
      throws Exception;
  }
  
  
  

----------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          cocoon-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-cvs-help@xml.apache.org


Mime
View raw message