July 25, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

The Two Faces of JSF on WLP

  • July 7, 2008
  • By Scott Nelson
  • Send Email »
  • More Articles »

IBM does it. Sun does it. Since 9.2, WebLogic does it. So, you can do it. Build JSF portlets.

With the yen for a bad song parody out of my system, JSF is seriously the up and coming technology in portals, even while JSR 301 is still in the early draft stage. In a recent bout of research on this topic, I was surprised to find that there is a JSF option for every J2EE-based portal I looked at. Even though I didn't look at them all for this piece, I did look at a fair sampling of both COTS and FOSS portals. There are very few that have only JSF portlets, but the fact that some many include it as an option demonstrates the popularity of JSF among those that make the platform decisions.

Of course, there are two (or more) sides to the cutting-edge sword. Early adoption is just plain cool. Every passionate developer likes to build something in a way that few before them have. And, in today's super-competitive market place, businesses that once waited for technologies to mature are now the front-runners in hopes of making up ground lost to the innovators of the last decade. JSF isn't new; what is (fairly) new is using it in portals. Because there isn't a fully defined standard for doing so yet, it's anyone's bet that if you build a JSF portlet using one set of tools, you may have to learn a whole new set in a year or two. Or, rewrite a good chunk of what you built when the standard is released.

The best advice I can give around early adoption is to minimize the use of proprietary libraries and not get too carried away innovating your own solutions to make a technology fit a solution. If a given technology isn't quite ready for your project requirements, use another approach. One of the benefits of building JSF portlets in WLP is that the tools beyond the standard JSF libraries are open-source.

No Going Back for Wizard Lovers

To use JSF in WLP, you first must enable the JSF facet in your portal project. Once you have done this, any Page Flow portlets you create with the wizard dialogues will be JSF Page Flows. You can still build standard Beehive Page Flows, but you'll need to start it manually.

If adding facets is new to you, it is very simple in Workshop and WorkSpace Studio. Right-click on the project and select properties. Select Project Facets and you will see a list of installed project facets and the Add/Remove button. Clicking the JSF checkbox and then Finish will install the defaults. If you are already well-versed in JSF or have specific version preferences, clicking "Next" will bring you to more detailed options.



Click here for a larger image.

Figure 1: Adding and Managing the JSF Project Facet

For new projects, you will see the same choice if you follow the "click Next" route in the project wizard rather than jumping straight to "Finish" after naming your project. If JSF is the only custom facet you need, there are fewer steps involved in adding the facet after you have created the project.

The Same, Only Different

With the JSF facet added, using the Page Flow wizard will generate the usual Page Flow controller and index.jsp. There are a couple of differences from the standard Beehive Page Flow files. The first difference is that the JSP will be a JSF JSP:

<%@ page language="java" contentType="text/html;charset=UTF-8"%>
<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%@ taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
<html>
   <head>
   </head>
   <f:view>
      <body>
         <f:verbatim><p>JavaServer Faces Page -
                        ${pageContext.request.requestURI}</p>
         </f:verbatim>
      </body>
   </f:view>
</html>

Note that the HTML head and body tags are included. Generally, these are undesirable in a portlet because they create an invalid DOM in a portal. However, some JSF libraries require this for compilation (another indication that the standards of JSF in portals are still incomplete), so you will need to make an individual call as to whether they should be removed for your particular portlet.

The other difference is that the forward defined for the JSF JSP has a .faces extension instead of a .jsp extension:

@Jpf.Controller(simpleActions =
   { @Jpf.SimpleAction(name = "begin", path = "index.faces") })

One new aspect when creating a Page Flow with the JSF facet is that a backing bean is generated for the JSF JSP. The backing bean created is a Beehive version:

package portlets.jsfPageFlowDemo;

import org.apache.beehive.netui.pageflow.FacesBackingBean;
import org.apache.beehive.netui.pageflow.annotations.Jpf;

/**
 * This is the default Faces Backing file for a JSF Page.
 */

@Jpf.FacesBacking()
public class index extends FacesBackingBean {
   private static final long serialVersionUID = 1L;
}




Page 1 of 3



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel