Zaphod – betterFORM As Service (Cross Context Environment)

This article describes how to use betterFORM from within a different servlet container context. It allows to store or generate forms in your application context and let betterFORM process the form in its own context.

Advantages

  • Easy and independently updating the software in the separated contexts.
  • Usage of the same software library in different versions. Since both software stacks are loaded from different class loaders the do not interfere each other.
  • Creating XForms from within your web application. The created form is processed in the context of betterFORM.

Disadvantages

  • more complex configuration

Prerequisites

  • The setup can only be used in one servlet container. Both contexts have to be deployed on the same servlet container. Distributed systems are not supported at the moment.
  • The servlet container must allow to access the context of betterFORM. Most servlet container allow this by default. Apache needs to be configured separately. The current distributions of betterFORM already contains a context.xml file which allows other contexts to access the context of betterFORM.
  • The distributed filter class muss be installed in the context which accesses betterFORM. An Jar file is (not yet) distributed.
  • The filter must me configured correctly. The filter is configured in the deployment descriptor of the web application.

Configuration

All the configuration is done in the deployment descriptor. betterFORM itself is already configured for this configuration. In the deployment descriptor one has to specify:

  • the URL for the filter.
  • the context name of betterFORM.
  • and URL which points back to the applications context

The filter is mapped to an URL pattern. If a request matches the pattern the returned page is send to betterFORM and processed as an XForm form. Under the URL one can store forms in files or servlets which generate forms.

The name of the betterFORM context is configured through the filter parameter xforms.engine.webcontext. It should contain the name of the context as string (defaults to ‘betterform’).

In the filter parameter xforms.engine.resource one must specifies an URL which points back to the filter. The url has to be appended with an virtual directory. This allows the filter to handle and forward requests which are resources within the betterFORM context. This applies to css, scripts and images distributed with betterFORM.

Additionally one can configure the servlet which processes forms in betterFORM. It is not recommended to change this variable. It is intended for development.

Examples for Apache Tomcat

The following example files should work with Tomcat 5.5.x and Tomcat 6.x.

Context.xml

This file is only needed when betterFORM is used together with Tomcat. It should be stored in the directory META-INF under the name context.xml. When first deployed Tomcat copies it to its own directory structure. Changes after the first deployment are not considered.

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" crossContext="true" path="/betterform"/>

Applications WEB.xml

This file shows a minimal setup. The setup renders all forms in the forms directory with the help of betterFORM into an html page. The setup specifies the context in which betterFORM is running. Its important that the path of xforms.engine.resources is set to the same directory as the patter of the filter.


<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
  <description>..</description>
  <display-name>Sample Application</display-name>
  <filter>
    <filter-name>CrossContextFilter</filter-name>
    <filter-class>de.betterform.agent.web.filter.CrossContextFilter</filter-class>
    <init-param>
      <param-name>xforms.engine.webcontext</param-name>
      <param-value>betterform</param-value>
    </init-param>
    <init-param>
      <param-name>xforms.engine.servlet</param-name>
      <param-value>/repeater</param-value>
    </init-param>
    <init-param>
      <param-name>xforms.engine.resources</param-name>
      <param-value>/SampleApp/forms/forward</param-value>
    </init-param>
  </filter>
  <filter-mapping>
    <filter-name>CrossContextFilter</filter-name>
    <url-pattern>/forms/*</url-pattern>
  </filter-mapping>
</web-app>

Status

The current status of this configuration is experimental. We have not yet used this setup with any of our clients. This is the first public release. So be warned!

In the current version the code should allow authentication. It does not support the configuration of betterFORM with absolute URLs.

The configuration of the filter in the WEB.xml is quite complex and error prone. I would be much better to generate the path to betterFORMs internal resources.

1 Comment Add your own

  • 1. Farah Zareen  |  April 4, 2013 at 5:07 am

    Hi,

    We are trying to use Betterform Zaphod to convert our Betterforms XForms into HTML. I am having an issue here – I am initially on a page with URI: /forms/home which has few submit buttons, each with a different resource-uri. method=”get”, and submission replace=”all”. When i click a button from “/forms/home”, i submit a “GET” request to a resource-uri called “/forms/getProfile”and get an xForms response back. But, betterForm-Full.js seems to be handling replace=”all’ by invoking fluxProcessor._handleBetterFormReplaceAll() that does a: window.open(window.location.href, “_self”);

    In my case, window.location.href will be /forms/home, but i need to submit a request to /forms/getProfile. Since it is trying to send request to location.href, i am getting incorrect response back. So, i have a few questions here:

    1. Why is it trying to submit to window.location.href. Based on the application, window.location.href could be different from the action/resource-uri the user wants to submit the request to.

    2. Why is it making this second request to window.location.href when the first request on submit actually gets the response back? This is causing my application to make two requests – first one to the resource-uri of the submitted target (button clicked), and other through window.open(window.location.href, _self)

    3. Is there a way to avoid this second request, if not how can i override window.location.href with the resource-uri of the button i clicked

    Any responses would be appreciated.

    Thanks,

    Arshad

    Reply

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


%d bloggers like this: