Resource server

The Resource Server serves resources such as images, CSS stylesheet or other static files. Resources are sent to the HTTP response untouched, and the HTTP cache control headers are set.

Config input

The config input contains a single url element containing an absolute URL. The URL can be any URL supported by your platform, in particular URLs with the following protocols:

• file
• http
• oxf (to access Orbeon Forms resources)

The Resource Server supports the deprecated use of a config input containing a single path element representing the absolute Resource Manager path of the file to serve. Since the url element also allows to access to Orbeon Forms resources, it is recommended to use it instead of path.

Mime types input

COMPATIBILITY NOTE: This input has been removed as of Orbeon Forms 4.7. The processor is deprecated as of Orbeon Forms 4.7.

The mime-types input contains a list of patterns and MIME Media Types. This mapping list determines which content-type header to send to the browser. The patterns are case-insensitive. Orbeon Forms is bundled with a default mapping file under the URL oxf:/oxf/mime-types.xml. You can create your own mapping to suit your needs. The RelaxNG schema is provided below.

The processor's mime-types input must conform to this Relax NG schema.

Example

The example below shows the Resource Server configured to send a PNG image file with the appropriate MIME type.

<p:processor xmlns:p="http://www.orbeon.com/oxf/pipeline" name="oxf:resource-server">
    <p:input name="mime-types">
        <mime-types>
            <mime-type>
                <name>image/png</name>
                <pattern>*.png</pattern>
            </mime-type>
        </mime-types>
    </p:input>
    <p:input name="config">
        <url>oxf:/images/logo.png</url>
    </p:input>
</p:processor>

Identity processor

The Identity processor is one of the simplest processors of Orbeon Forms: it simply copies the content of its data input to its data output. While at first this doesn't seem like a very useful feature, it actually can be very convenient, for example in the following scenarios.

Embedding XML documents

XML documents can be embedded within pipeline inputs. When you want the same document to be passed to the input of multiple processors in a pipeline, instead of duplicating it and embedding it in every input, you can use the Identity processor: embed the document in the data input of the Identity processor, assign an id to the output of the Identity processor, and reference that id from other inputs you want to feed with that document.

<p:config xmlns:p="http://www.orbeon.com/oxf/pipeline">
    <!-- Embed employee data -->
    <p:processor name="oxf:identity">
        <p:input name="data">
            <employees>
                <employee>
                    <first-name>Joe</first-name>
                    <last-name>Dalton</last-name>
                </employee>
                <employee>
                    <first-name>Averell</first-name>
                    <last-name>Dalton</last-name>
                </employee>
            </employees>
        </p:input>
        <p:output name="data" id="employees"/>
    </p:processor>
    <!-- Apply a first transformation on the employee data -->
    <p:processor name="oxf:xslt">
        <p:input name="config" href="oxf:/transform-1.xsl"/>
        <p:input name="data" href="#employees"/>
        <p:output name="data" id="result-1"/>
    </p:processor>
    <!-- Apply a second transformation on the same employee data -->
    <p:processor name="oxf:xslt">
        <p:input name="config" href="oxf:/transform-2.xsl"/>
        <p:input name="data" href="#employees"/>
        <p:output name="data" id="result-2"/>
    </p:processor>
    <!-- ... -->
</p:config>

Aggregating and modifying documents

Pipeline inputs support aggregation with the aggregate() function, as well as the XPointer syntax. The Identity processor can then be used to aggregate or otherwise modify existing documents in a pipeline, for example before sending a result to a pipeline output.

<p:config xmlns:p="http://www.orbeon.com/oxf/pipeline">
    <p:param type="output" name="data"/>
    <!-- ... -->
    <!-- Assuming the XSLT transformations in the previous example, transform the two results and send them to the data output -->
    <p:processor name="oxf:identity">
        <p:input name="data" href="aggregate('result', #result-1#xpointer(/*/*), , #result-2#xpointer(/*/*[position() *lt; 10]))"/>
        <p:output name="data" ref="data"/>
    </p:processor>
</p:config>

Debug processor

The oxf:debug processor logs XML documents to the Orbeon Forms log output. It has 2 inputs: data contains the XML document to log, and config has a config root element that contains a message typically be used to describe the XML document. The data output document is the exactly the same as the data input document. Consequently the debug processor can be easily inserted in a pipeline to log the XML data flow at a given point.

For instance, the processor can be called with:

<p:processor name="oxf:debug">
    <p:input name="config">
        <config>Employee</config>
    </p:input>
    <p:input name="data">
        <employee>
            <firstname>John</firstname>
            <lastname>Smith</lastname>
        </employee>
    </p:input>
    <p:output name="data" id="emp"/>
</p:processor>

This will generate the message:

Using debug attributes in pipelines is a shortcut for inserting the oxf:debug processor in the pipeline: the oxf:pipeline processor will automatically insert a oxf:debug processor when encountering debug attributes. By changing processors.xml you can map the oxf:debug processor to your own "Debug processor". If you decide to implement your own oxf:debug processor, note that it must have the same interface as the default oxf:debug processor that comes with Orbeon Forms.

TagSoup processor

<p:processor name="oxf:tag-soup">

    <p:input name="data">

        <document xsi:type="xs:string" content-type="text/plain">

            <span>Header</span>

            <br>Footer

        </document>

    </p:input>

    <p:output name="data" id="html"/>

</p:processor>

<html>

    <body>

        <span>Header</span>

        <br clear="none"/>

        Footer

    </body>

</html>

Redirect processor

The Redirect Processor allows redirecting or forwarding the execution to a new URL:

• Client-side the browser is redirected to another URL. Typically, for a Servlet environment, the sendRedirect() method is called on the HTTP response object.

  If the redirection URL is an absolute path (e.g. /hello) then it is interpreted as a path relative to the Orbeon Forms Servlet context (i.e. if your Orbeon Forms WAR file is under /ops, then the resulting path is /ops/hello). For other purposes, including redirecting to a path within the same Servlet container but outside the Orbeon Forms WAR context, you have to use an absolute URL complete with scheme and host name.

• Server-side: a server-side forward is executed. Typically, for a Servlet environment, the forward method is called on a Servlet request dispatcher.

The processor's data input must conform to this Relax NG schema.

The optional boolean server-side element determines whether a server-side forward is performed. The default is false.

This example creates a processor that redirects the browser to /login?user=jsmith:

<p:processor xmlns:p="http://www.orbeon.com/oxf/pipeline" name="oxf:redirect">
    <p:input name="data">
        <redirect-url>
            <path-info>/login</path-info>
            <parameters>
                <parameter>
                    <name>user</name>
                    <value>jsmith</value>
                </parameter>
            </parameters>
        </redirect-url>
    </p:input>
</p:processor>