Comments on: JSF and Mobile Web Applications — Part 2: The ServletFilter approach

By: James F

James F — Wed, 04 Jun 2008 20:31:52 +0000

Have you heard about the book, Pro JSF and Ajax? There’s a chapter on ‘Dynamically changing the renderkit’, which sounds interesting on the face of it. That may allow you to reduce the number of permutations of templates that you need to create for each markup language, and perhaps use multiple templates to optimize for screen-size.

http://www.springerlink.com/content/v123xm51gj7j27n3/

By: Austin Huang

Austin Huang — Thu, 03 Jan 2008 17:11:48 +0000

Hi, I tried JSF 1.2 RI (with Seam 2.0.1.CR1) embeeded in Jboss 4.2.2.GA. Seems that JSF 1.2 RI is not completely javascript-free implementation. Hereunder is the code

And I got

//

I am wondering is there any other JSF implementation for rendering XHTML MP ?

By: Marcus

Marcus — Thu, 27 Sep 2007 18:22:29 +0000

I do put some config for both template, and themes into components.xml, left it out for brevity.

By: Marcus

Marcus — Thu, 27 Sep 2007 18:18:24 +0000

@Name("template") public class Template extends AbstractMap implements Serializable {


  @In Theme contextTheme;
  @Override public String get(Object key) {

    // do whatever you need to select the right

    // template based on the key, device, config, etc.

    //

    // I also allow an override from a request param.

    //

    // Note that this doesn't remove the need for a

    // separate theme component (also a map). The one

    // that comes with Seam can work but is generally

    // too simplistic.

    return contextTheme.get(templateKey);

  }

@Override public Set> entrySet() { // this return doesn't matter too much return contextTheme.entrySet(); } }

ContextTheme is a simple manager component with one method that selects and returns the right Theme component depending on the context.

It’s not really groundbreaking but works nicely for me.

By: Michael Yuan

Michael Yuan — Thu, 27 Sep 2007 05:20:13 +0000

Hi Marcus,

Thanks for sharing your thoughts! Yes, I think my approach should be able to handle different sitemaps for different screen size templates. For instance, the small screen version of the “product description page” might be broken into multiple parts with “next page” links on each page. All I need is to put the “next page” link on the template for this screen size. The other large screen pages will simply not render that link and the user will not be prompted to go to the next page, right? So, I guess it should work as long as we keep each set of templates internally consistent. They are accessed by common URLs (e.g., /app/product.seam?id=123 always gets product 123 customized for the request device), but some URL (e.g., /app/product.seam?id=123&page=2) only works for certain screen sizes.

As for the manager component to replace my URL rewriting component, can you provide more details (a code snippet? :))? Do you use get() to get JSF rendered content? How do you do that exactly? Thanks!

cheers
Michael

By: Marcus

Marcus — Wed, 26 Sep 2007 21:44:38 +0000

This is great. I was working on this very issue in the past couple weeks (in Seam, no less) and I feel that this is very very close to the solution.

I feel though that there may be some big weaknesses to the filter + template approach. I think you even touched upon the very issues I’m concerned about in your previous post on the topic: The differently sized devices, even in a highly planned and structured web application, have different strategic goals in the planning of their site maps. So I see the site map as changing substantially when we’re talking about (a) extremely small screens, (b) small and medium, and (c) PC.

So the separate template are likely a necessity for different device size types, as you have stated, but there are also separate site maps for some or all of the device sizes in many or all cases.

What do you think? Does this mesh with your approach much or at all?

BTW, alongside iPhones for the medium sized devices, I’m thinking perhaps we could put set-top boxes, perhaps in two categories: HD and regular TV, depending on how important those markets are for a given application. But I haven’t explored that very far yet. Depending on how important those devices are for a given application, this may bring in color correction considerations, and alternative input device considerations, but really shouldn’t be too hard overall.

Also, regarding URL rewriting for templates, I don’t think it has to be all the way out there in the URL rewriter. The way I’ve implemented is just in simple manager components and components that implement Map with the template choice within the get(). It seems to me that the URL rewriter is really for external request translation, rather than internal. Does that make sense?