Did you mention you wanted a mobile version?

Today I worked on the mobile version of my Orbeon Forms application. I had to go through some trial and error but I was once again amazed at how quickly I managed to get something significant out there.

Essentially, my current webapp is laid out for a desktop monitor form factor. Having downloaded the latest WebKit mobile browser emulator for Win32, my tests showed that this little engine was right up there with the big guys in terms of JavaScript, CSS and XHTML support. This browser technology is available now on the Apple iPhone and very soon on Android, Palm Pre, Black Berry etc. Maybe more on this subject later but for the time being, I want to discuss how I got my application to be smartphone friendly in just a few hours. Sure, I still have some work to do but the basic foundation is there.

Essentially, I just had to create a handheld friendly version of my CSS and epilogue files. I also created a folder for the handset navigation. The page-flow.xml file in this folder refers to oxf:/config/handheld-epilogue.xpl instead of pointing to the standard epilogue.xpl program. Tweaking handheld-epilogue.xml was trivial. The harder part was tweaking the handheld friendly version of my CSS (thank God we can rely on Firebug for help). I also created and used a file to replace my theme.xsl which allowed me to remove the superfluous content from the interface and produce pages that make near optimal use of the small screens. In fact, I was able to reuse existing pages without any reengineering which is really the most rewarding aspect of the whole exercise.

I even had time to experiment with redirection of http requests based on user-agent sniffing. Pretty easy to do actually so now, if someone points a smartphone at my application, she gets automagically redirected to the handheld formatted content. Pretty cool don't you think? I must admit that the guys (and gals perhaps) at Orbeon are doing a tremendous job and that although Orbeon Forms may present a relatively steep learning curve up front, the dividends are there for the long haul.

So long,

A Spring Loaded Pipeline Processor for Orbeon

As many Java developers and architects know, the Spring framework is a very effective tool that facilitates Java development and makes it more enjoyable. Being myself an aficionado, I was looking for a way to use Spring configured services from within my Orbeon XForms application. My idea and requirement was essentially to be able to access these services from within Orbeon pipeline processors (XPL). While the final and ultimate solution is still to come, I thought I should present the basic idea and preliminary implementation here and possibly get some feedback and suggestions.

My solution is quite generic and makes use of Java reflection (just as Spring does) to expose Spring configured POJOs to pipeline programs. Essentially, the end result as it is used inside an XPL program looks like this:

<p:processor name="wf:javaServices">
  <p:input name="instance" href="#input-doc"/>
     <p:input name="config"> 
        <config service="userServices"
          javaType="com.opnworks.workforse.ops.processor.UserServicesBroker"
          method="getUserDetails"
          xsl:version="2.0">
        <argument type="xsd:string">arg1</argument>
        <argument type="xsd:string">arg2</argument>
        <argument ref="instance"/>
     </config>   
  </p:input>
  <p:output name="data" id="result" />
</p:processor>

In the above XPL element, we use a custom processor (wf:javaServices) that was registered as an Orbeon processor in the custom-processor.xml file. This processor requires a "config" input which identifies the Java bean defined in the Spring application context. This is done by using the @service attribute on the <config> element. This attribute corresponds to the name of the Spring-defined baen in hte applicaiton context. We must also specify a javaType attribute specifying the class (or interface) of the bean or service that we want to access. Finally, the @method attribute contains, as you have already guessed, the name of the method we want to invoke. Finally, the <config> element contain 0 or more <argument> children corresponding to the method arguments. These can be scalar values in which case we need to specify a type in the @type attribute. Alternatively, an argument can contain a reference (using the @ref attribute) to one of the processor inputs (an XML document) that will be passed to the service through the method. Naturally, the order of the arguments is important since the information specified in the <config> element will be used to reflectively lookup the method on the Java class specified in the @service attribute.

My custom processor extends org.orbeon.oxf.processor.SimpleProcessor and basically defines the following method. Note that this processor needs to be able to access a Spring application context (the ctx variable in code below) and this context is typically loaded at the time the custom processor class is loaded.

public void generateData(PipelineContext context,
ContentHandler contentHandler) throws SAXException {

Element configRoot = readInputAsDOM4J(context, "config").getRootElement();

String serviceName = configRoot.attributeValue("service");
String serviceType = configRoot.attributeValue("javaType");
Class clazz = null;
try {
   clazz = getClass().getClassLoader().loadClass(serviceType);
} catch (ClassNotFoundException e1) {
   throw new OXFException(e1);
}

Object service = ctx.getBean(serviceName, clazz);

String methodName = configRoot.attributeValue("method");
List<Element> argumentNodes = configRoot.selectNodes("//argument");
Object[] arguments = new Object[argumentNodes.size()];
Class[] parameterTypes = new Class[argumentNodes.size()];

for (int i = 0; i < argumentNodes.size(); i++) {

   String type = argumentNodes.get(i).attributeValue("type");
   if (type == null) {
      Document doc = readInputAsDOM4J(context, argumentNodes.get(i).attributeValue("ref"));
      arguments[i] = doc;  
      parameterTypes[i] = Document.class;
   }
   else {
      arguments[i] = getAttributeValue(argumentNodes.get(i));
      parameterTypes[i] = arguments[i].getClass();
   }
}
try {
   Method method = service.getClass().getMethod(methodName, parameterTypes);
   Document doc = (Document) method.invoke(service, arguments);
   LocationSAXWriter saxWriter = new LocationSAXWriter();
   saxWriter.setContentHandler(contentHandler);
   saxWriter.write(doc);
} catch (Exception e) {
   throw new OXFException(e);
}
}

This approach works like a charm and allows me to extend ad infinitum the scope of the java services I want to expose to XPL programs without having to write and register additional processors.

What do you think?

Orbeon Development Tips

Debugging XPL pipelines

Debugging a pipeline (XPL) is not always easy but Orbeon has a handy "debug" attribute that can be added to any <p:input> or <p:output> . When this attribute is present, the document that passes through that input or output is logged to the Orbeon Forms log output. For example:

 <p:input name="data" href="#instance" debug="update-profile-instance"/>

Including custom CSS stylesheets

The Orbeon examples seem to suggest that if you need custom styles in your xforms page, you need to add inline styles directly in your page. In fact, trying to add a <link href="".../> does not work out of the box for some reason (I presume it is somehow related to the processing done by the epilogue processor). Anyway, this is not a problem if you have special needs for a specific page but if you want to reuse your style definitions across several pages, the cut and paste approach is simply not acceptable.

Here is a trick I found to easily add a file-based stylesheet to Orbeon xforms pages. Simply insert an element such as the following in the head section of your page:

 <xi:include href="oxf:/config/theme/my-styles.css"/>

Obviously, you need to add the "xi" namespace to your pages.

Epilogue (!)
Don't be shy to share your tips with other readers by commenting on this article.

Spring Security for Orbeon

My main Orbeon application was using the Tomcat Realm security mechanism which turned out to be fairly easy to use and setup. I even wrote a simple Java class to authenticate users against an eXist (XMLDB) database. But I needed more flexibility and robustness and my colleague Pedro suggested I should use the Spring Security framework (aka ACEGI security). I had worked with ACEGI security in previous projects and knew how powerful and flexible it was but from what I could recall, it's configuration and use was not trivial. Well, that has changed quite a bit with the new 2.x version, now an official component of the Spring framework and called "Spring Security".

In fact, I can say that it took me less than half a day to get everything up and running with authentication for my Orbeon-based web app being done against an SQL database. Now, I just have to setup my access policies and roles to exploit the power and flexibility of this framework. I also have the flexibility to eventually add password encryption, LDAP authentication, ACLs etc.

On the more practical aspects, here is a simple rundown on what needs to be done.
First, I was hoping I could use only a small subset of the Spring jars but at the finish line, you need most of the jars that come with Spring. Here is the list of jars I finally ended up with:

• spring-security-core-2.*.jar
• org.springframework.aop-3.*.jar
• org.springframework.beans-3.*.jar
• org.springframework.context-3.*.jar
• org.springframework.core-3.*.jar
• org.springframework.expression-3.*.jar
• org.springframework.jdbc-3.*.jar
• org.springframework.transaction-3.*.jar
• org.springframework.web-3.*.jar
• com.springsource.org.antlr-3.0.1.jar
• commons-logging-1.0.4.jar

Here are the elements I added to my web.xml file:

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/spring-security-context.xml</param-value>
</context-param>

<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

The content of my spring-security-context.xml file is:

<beans:beans xmlns:beans="http://www.springframework.org/schema/beans"
xmlns="http://www.springframework.org/schema/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
      http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.4.xsd">

<http auto-config='true'>
 <intercept-url pattern="/auth/login*" filters="none" />
 <intercept-url pattern="/wfdemo/**" access="ROLE_USER" />
 <form-login login-page="/auth/login" />
</http>

<authentication-provider user-service-ref='userDetailsService'/>

<beans:bean id="authDataSource"
 class="org.springframework.jdbc.datasource.DriverManagerDataSource">
 <beans:property name="driverClassName" value="com.mysql.jdbc.Driver" />
 <beans:property name="url"
  value="jdbc:mysql://localhost:3306/***" />
 <beans:property name="username" value="???" />
 <beans:property name="password" value="****" />
</beans:bean>

<beans:bean id="userDetailsService"
 class="org.springframework.security.userdetails.jdbc.JdbcDaoImpl">
 <beans:property name="dataSource" ref="authDataSource" />
</beans:bean>
</beans:beans>

As for the login form, I just had to change the action attribute value to "j_spring_security_check" as such:

<form action="/j_spring_security_check" method="post">

I obviously had to create a database and tables used by the userDetailsService. The Spring documentation contains details on the DDL.

Et voila! I have form-based authentication for my Orbeon application using JDBC and Spring Security configured with a Spring application context.

That's pretty much all there is to it folks.

Have fun with Orbeon and Spring!