2008-12-16

Upgrading a JSF 1.1 project to JSF 1.2

I've just upgraded a project from JSF 1.1 (MyFaces) with tomahawk to JSF 1.2 (Mojarra) with Facelets. Halfway through the process I realized it would be worth sharing, since I would have appreciated if somebody else had done that before me. (There is a description about how to make a new project with JSF 1.2 on http://forums.sun.com/thread.jspa?threadID=5156242, but I wanted to upgrade an old project.)

Facelets is XML

Because facelets are xml documents you need to change && in your expression language statements to && (I found the tip here: http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=82&t=001835.)

Update 2008-12-23: If you're smart and read the documentation, you might also find out that you can just write and instead of both && and &&.

Also remember that xml comments are written as <!-- --> instead of <%-- --%>

We don't need the tomahawk taglib any more!

While I appreciate the effort that people has put into MyFaces/tomahawk, it also became a major hurdle in the process of upgrading the application. The reason is that it took very long time before the developers announced a JSF 1.2 compatible version, and by that time, I was already decided to get rid of that taglib.

We mainly used to use the tomahawk library for 4 different things:

t::updateActionListener

<t:updateActionListener value="#{fooBean.bar}" property="#{bazBean.bar}" /> can now be substituted with <f:setPropertyActionListener value="#{fooBean.bar}" target="#{bazBean.bar}" /> in the standard f: taglib.

t:dataList

t:dataList can be substituted with rich:dataList

forceId

The components in the tomahawk taglib has an attribute called forceId which overrides JSF's id generation, allowing you to specify the precise id you want for a tag.

There's no such things as a forceId attribute in any of the other taglibs we use, but luckily, with facelets you can now use plain html tags if that is what you want. Also, much of the reason for using forceId was for selenium testing. Later on, I learned that we could use xPaths with selenium to pin down a page element without resorting to the id. (If you decide to try, there is at least two different Firefox plugins that you can use to find the xpaths, and at least one of them is useable, I just can't remember the name.

The last reason for using tomahawk was either the sortable table or the fileUpload component. Luckily, both are easily available in the rich taglib.

http://www.google.com/search?complete=1&hl=en&q=Bean+or+property+class+javax.faces.model.SelectItem[]+for+managed+bean++cannot+be+found.+&btnG=Google+Search&aq=f&oq=

Using arrays in faces-config.xml doesn't work

At least not i mojarra. Here's my changes:

- public SelectItem[] getFooBarOptionList() {
+ public List getFooBarOptionList() {
      List optionList = new ArrayList(FooBazFooBarEnum.values().length);
      for (FooBazFooBarEnum fooBar : FooBazFooBarEnum.values()) {
          optionList.add( new SelectItem(fooBar.getValue(), fooBar.getValue()));
      }
-     return optionList.toArray(new SelectItem[optionList.size()]);
+     return optionList;
  }
  <managed-property>
-   <property-name>fooBarOptionList</property-name>
-   <property-class>
-    javax.faces.model.SelectItem[]
-   </property-class>
-   <value>#{fooBazDetailFilterBean.fooBarOptionList}</value>
-  </managed-property>


<managed-property>
+   <property-name>fooBarOptionList</property-name>
+   <property-class>java.util.List</property-class>
+   <value>#{fooBazDetailFilterBean.fooBarOptionList}</value>
+  </managed-property>

One last thing:

Here's some code to fetch whatever managed bean you need without injection. I don't suggest you should do anything like this, but if you have already done it, and need to upgrade to JSF 1.2, here is how:

From:

public static Object getBean(String beanName) {
    return getContext().getApplication().getVariableResolver().resolveVariable(getContext(), beanName);
}

To:

public static Object getBean(String beanName) {
    return getContext().getApplication().getELResolver().getValue(getContext().getELContext(), null, beanName);
}

Remember: use with caution, as the result may be hard to unit test.

3 comments:

  1. Hi, I'm not a JSF expert and use the following code a lot
    getContext().getApplication().getVariableResolver().resolveVariable(getContext(), beanName);

    Can you please tell me what is the best way to lookup Managed Beans.

    ReplyDelete
  2. Yes, 'll give it at try at least, I haven't been using JSF for three months so it's starting to fade away :)

    Normally, when you want one managed bean(A) to access another(B), you declare a field with the type off the bean you want to access in A, and inject an instance of the bean you want to access (B) into this field.

    And, yes, as you probably guessed, this isn't lookup, - it's injection.

    ReplyDelete