JSF and Mobile Web Applications — Part 1: What looks good on paper doesn’t always work out
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:
- 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.
- 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.
- 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?
- 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.
- 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!
September 25th, 2007 at 12:03 pm
Hey Michael,
I faced similar challenges when building a mobile portal for a large Canadian carrier back in 2001. We had a single ‘render kit’ that minded content blocks kind of like portlets from a content repository. The content blocks were XML and we transformed them on the fly using XSLT, different stylesheets for different devices. If the output of JSF tags were templated externally, the renderkit can stay consistent and only the templates change per device.
Content was tagged as cosmetic (only rendered to something like a PC or Treo) and also ‘verbose’ and ‘brief’. We used brief versions of content on smaller devices and rendered verbose content blocks for web browsers.
All media (images, sounds, etc) were served from a media server that transformed according to the device accessing the portal.
It’s very fun playing in the mobile space. Lots of challenges
September 25th, 2007 at 1:11 pm
Don,
Thank you for sharing the experience! So, you guys wrote your own renderkit to plug into JSF? Any chance you might share it as open source?
The approach I am thinking about right now is to use ServletFilters to dispatch to different device templates. It should be quite similar to your renderkit approach. I will discuss it in the next blog post tomorrow!
cheers
Michael
September 25th, 2007 at 2:45 pm
Alas, this was WAY before JSF and even before portlets were really finalized.
We had a component that acted much like JSF in that it built a component tree and then rendered output, but the content in the tree where content items that the user subscribed to. It was kind of like an RSS aggregator - a user could subscribe to content (news, weather, new game announcements, etc), each subscription would result in a block of content being rendered and the main portal engine would just aggregate this together as a single blob of XML. We’d then transform the XML using XSLT (again, potentially a different XSLT per device) and render to the device (at the time we supported HTML (for IE and Netscape/Mozilla), XHTML (for the one Sony Ericsson device that supported it) and WML (including OpenWave’s variant)).
I wish the JSF renderkit was a lot more generic. For each JSF tag, I wish one could specify a template. Certain tags like grids and tables need several fragments as part of the template (top, ‘middle’ and bottom parts). I wish the templates themselves would support EL. I wish one could plug in a TagTemplateResolver so that templates could be resolved at runtime (return different fragments depending on device, website ‘branding’, etc). This would facilitate theming JSF based sites in a very simple, extensible way in addition to supporting multiple devices easily.
I’ve thought about writing a render kit that could do all this, but there is so little time in the day
September 25th, 2007 at 2:50 pm
Oh, and in my last job (Virgin Mobile Canada), we had an easier time supporting devices. We always rendered XHTML and used a servlet filter to transform that into WML when we needed to. One gotcha is special WML characters that need to get escaped (like the dollar signs and French characters to entity references).
The mobile website was completely different jsps than the desktop browser website in this case.
September 25th, 2007 at 3:08 pm
Thanks Don for the info! Yes, WML is hard to deal with. Fortunately, most new mobile web apps today will only need to worry about XHTML MP — it is still a hassle to deal with device-to-device variations, but it is a lot better than WML!
September 25th, 2007 at 7:18 pm
Michael, Thanks for kicking off this . We will be waiting for your future posts. We are using Trinidad JSf library and experimenting how much it would help in delivering mobile content. Trinidad has ( as you might know ) , default PDA support and we are trying to control sizes of the components using PDA skin.
It would be great to see some inputs on above approach , any other better libraries or Mobile support .
Thanks again.
September 25th, 2007 at 9:48 pm
Perhaps I am not reading into the spec enough, but I don’t think anyone really expected to be able to use the *same* Facelet template (or JSP if you are masochistic) to render different output formats. I think the idea is that you can use the same familiar UI components that render different markups. For instance, you might have a rating widget () that renders in one way for HTML but another way for WML or XUL. The actions may even be queued differently, in one case Ajax, in the other a regular form submit. The developer doesn’t have to shift their mindset since the name and attributes of the tag is still the same.
I guess you *could* assume the design was to support the exact same template, but it is so laughable that most people just didn’t take it seriously.
Dan
September 25th, 2007 at 9:58 pm
Sudhir,
I have not personally used Trindad. However, I’d like to note that the web browsers on PDAs are actually quite close to desktop web browsers — you still need to worry about screen sizes etc. but you do not typically need a different markup language.
cheers
Michael
September 25th, 2007 at 10:10 pm
Dan,
To my knowledge, the original JSF marketing message was exactly that: “generate multiple content outputs from the same page so that you can write once and access it everywhere.”
The approach you mentioned obviously makes more sense and it is indeed how ASP.Net is used in the mobile world. ASP.Net advocates that you can drag and drop the same UI controls onto the regular web page and a mobile web page. It will render differently depending on the device.
However, ASP.Net has very good drag-and-drop UI designers for a variety of screen sizes, and more importantly, has a renderer that actually works …
cheers
Michael
September 26th, 2007 at 4:39 am
Don Kittle wrote: For each JSF tag, I wish one could specify a template. Certain tags like grids and tables need several fragments as part of the template (top, ‘middle’ and bottom parts). I wish the templates themselves would support EL. I wish one could plug in a TagTemplateResolver so that templates could be resolved at runtime (return different fragments depending on device, website ‘branding’, etc). This would facilitate theming JSF based sites in a very simple, extensible way in addition to supporting multiple devices easily.
We don’t use JSF, but this is exactly the approach we use for the combined web/mobile portals that we produce at iO Global. We use Mojasef which allows dynamic selection of progressively finer-detailed markup fragments. There is absolutely no difference between the Java code for web and WAP flavours, it’s all done by constructing returned pages from template fragments.
September 26th, 2007 at 10:16 am
Frank,
Thanks for the comment! Mojasef does look like a great project!
cheers
Michael
September 26th, 2007 at 10:19 am
Don,
You might want to look into Facelets — it provides per-tag templates. It might be something that you want!
cheers
Michael
November 30th, 2007 at 7:21 am
Michael,
You migh want to look into mobile-jsf rendererkit from ericsson: http://www.ericsson.com/mobilityworld/sub/open/technologies/open_development_tips/tools/mobile_jsf_kit
It follows the one source/multiple targets approach…
Regards,
Marc
February 17th, 2008 at 3:17 am
Thanks Marc! The ericsson mobile-jsf kit looks really really promising. I hope that I can free someone up in team in order to check it out.
Has anybody already made some experiences with integrating Mobile-JSF with SEAM?
Regards, Raimund