Michael Yuan

Update: Please see Dan Allen’s comment below for an alternative view. I do agree with him that component level multi-rendering makes sense. But without a good, production ready renderkit, all the practical problems listed in this blog post still exist. The bottom line is that we need a renderkit that can dynamically detect the device, dispatch to different page templates based on the device, render standard JSF components into multiple markups, and generate customized content for the device. That far exceeds the capability of any renderkit out there …

One of the much touted benefits of JavaServer Faces (JSF) is its capability to render multiple outputs from the same view page. For instance, in theory, the same JSP page can be rendered into WML/CHTML/XHTML MP for mobile phone browsers and regular HTML for PC browsers. However, no one uses that in the real world for a couple of very good reasons. The static JSF renderkit for “mobile content” just does not cut it:

1. The mobile phones and PCs have very different screen sizes and media capabilities. It would be silly to assume that you can use the same page layout and display the same type of contents for both use cases. If forced to do, the developer will just have to use the lowest common denominator and ruin the user experience. More than likely, you will need different view templates for phones and PCs. Hence the entire point of “reuse the view page” is moot.
2. Even if it is possible to reuse the page, the price you pay is to write the page entirely in JSF tags. There must be no regular XHTML/HTML/WML tags in the page for this to work. That does not bode well with almost all web page authoring tools. The rendered page is opaque to page designers. As we have seen many times, web developers prefer to construct the page template primarily in “regular” markups and only use JSF tags for specific input / data components.
3. Since the JSF renderkit is statically configured in faces-config.xml, you cannot have mobile web pages and regular PC web pages co-exist in the same web application. That is really silly and very limiting — what is the point of page reuse if you have to deploy two web applications to serve those pages?
4. While JSF can generate WML/XHTML tags from the same page, it does not address deeper content transformation issues. For instance, you will probably need to display different images on different devices based on the target screen size.
5. Finally, probably because of the above, there is really no production quality mobile renderkit out there for JSF. MyFaces has a basic WML renderkit. But it is just for demo and has not been updated in a long time. There is no renderkit for XHTML MP.

One way to address issues #3 and #4 is to build some user agent detection logic into the renderkit. The renderkit figures out the device type of the incoming request and generate the right tag / image for it. For instance, the following user agent indicates that the request comes from a Nokia 6600.

Nokia6600/1.0 (5.27.0) SymbianOS/7.0s Series60/2.0
Profile/MIDP-2.0 Configuration/CLDC-1

This user agent causes the renderkit to generate XHTML MP tags with all images on the page resized to below 240 pixels wide. The down side, however, is that renderkits are pretty complex to develop and we still have not addressed issues #1 and #2.

In the next post later this week, I will propose a better solution to develop mobile web applications with JSF and potentially other web frameworks. Stay tuned!