Blog

Being asked to research application frameworks and then reporting back is a pleasant deviation from the usual grind of production deadlines and code review due dates. So, when the opportunity came up to do some heads-down review on what is available for a client looking to convert a rather extensive JavaServer Faces (JSF) application into portal ready portlet components for WebCenter Interaction (WCI) - we were giddy. (Not Christmas Day snow giddy, but it was almost close)

SPRING

First up was the Spring framework, but the problems we encountered here centered around our application and the Ajax calls it wanted to make and the resulting back and forth of JSON data. The data needed to properly flow from the application front to back-end and what we were seeing was a conflict between the Ajax remoting and the portal. When setting the 'ContentType' to the proper value of "application/json" the portal throws back an error code of 415, a quick lookup reveals that Error 415 corresponds to "unsupported media type", not what we want to see - so we took a look into fixing it.

A deeper dive into the header data flying to and from the server revealed that the header information was being set properly to be "application/json", but on the return trip from the portal the content was now of content type "application/x-www-form-urlencoded". Unselecting "Inline refresh" as a portal setting cleared this content type issue but we need to use the "Inline refresh" option in our portlets since the application utilizes Ajax and jQuery and toggling the "Inline refresh" option off would break this functionality.

So Spring is giving us some early round headaches and it did not look as though Spring, our application, and the WCI Portal were going to play nice with each other.

JSF

The next approach we considered was to keep with the framework that the client already had in place, JSF, and massaging what already existed to integrate appropriately into the portal in portlet form.

To start, plain and simple, we can use an IFrame. The application exists, we can place a header and a footer to wrap it up, tie a bow at the end and take an early happy hour. While using an IFrame as a solution is entirely plausible, simple, and does the job - it is more of a middle man step than a full bodied solution, we have no portlets (unless the IFrame is being counted as one huge portlet), there is no reusable component breakdown, and most importantly, all we have done here is punched a hole through the portal and dressed it as a window to view the application through. So we will not be recommending this as a final solution if a portlets are the end targets, and they are.

With JSF there are some speed bumps when trying to bring an application over to the portal.

1. Buttons. They do not work. JSF applications rely on the button name-value pair for navigation rules to take effect. Unfortunately for us, the portal inline refresh implementation ignores buttons when it does the post back for the forms. Are there work-arounds for this issue? Sure, we can dirty up the behind-the-scenes a bit with a littering of hidden variables for all of the data we would be losing on the buttons, but this approach is by definition redundant, and fairly messy at a first glance for maintenance. Alternatively we can create a custom renderer for the HTMLButtonRenderer class, and from there ... well, that's a bit of work, and we still have more issues with our actual JSF application friend who has been ignored for quite some time now.
2. a4j - This is the framework that adds beautiful and convenient Ajax capabilities to JSF. The problem is that the portal has its own Ajax library and the calls made clash all over the place with the a4j functionality. We could turn inline refresh off to fix this problem, but then our application stops working entirely, so that is a moot point.
3. The back button - a pretty common issue in JSF applications, but the browser back button is no longer going to behave in a responsible manner. The work-around for this is to provide a custom navigation element that will address this issue.
4. The JSF Portlet Bridge - the idea here is that you have an application (check), and you are trying to turn it into portlets (go on ...), and the Portlet Bridge is just that, it bridges an application into the portlet realm. This sounds nice, and fits with our needs, so what is missing here?

It turns out that a few things are missing; Portlets reside in 'portlet containers' and as our application has only ever existed as a large Hulk of an application we will need a portlet container somewhere to serve up our portlet to the portal. The next missing bit is that the portlets that will be created here need to be presented through a WSRP Producer and the content that is offered up by the WSRP Producer needs to be consumed by the portal via a WSRP Consumer, and neither of these components are installed or even known to the client yet.

STRUTS

The last framework that we presented was Struts, being one of the oldest model-view-controller frameworks we had high hopes for compatibility with what we needed to accomplish. Having been around a while, Struts has received a fair share of critiquing in regards to its heyday having passed. But that said, if it is still a viable solution and a proper fit to plug the hole that is present, ultimately the technology you use is not there because it is on the bleeding edge of hacker screens, but because it is appropriately useful for you.

There was a slight concern on how Struts would handle Ajax, but it was a slight concern, at its worst. A quick search lead us to the plugins available that would resolve the problems that bubbled up from our prototype application. Function1 has also implemented a number of customizations between the portal and portal classes in the form of a bundled utility package that contains the tweaked code we have used in the past to resolve lingering quirks in behavior between the portal, Ajax, and Struts.

HOMEWORK DONE

At the end of the day though, the prep work we have done here and the small exercises in prototyping we have gone through are primarily for client consideration, we present what we find and place forth a strong recommendation on where we think the integrated direction should be, but being flexible in any approach is still key - working with the decisions made will be the step after this one.

In the next phase of the project decisions will be made based on our recommendations, the development work will begin, the integration meetings will spin up again, and due dates will be reminded to us as they crop up, but it's nice to have a change of pace from heads down coding and provide a broad level of insight to a customer on the array of technologies available to them, keeping some people informed - and who can complain about a little homework now and then.