Learning JSF2: Using Flash scope

JSF 2 provides two new scopes on top of the standard Servlet scopes (request, session, application). One of them is the view scope. View scope was covered in Managed beans article. The other scope is Flash which I’m going to cover here. Let’s start with a very simple example.

Managed bean:

@ManagedBean(name = "bean")
public class Bean {
   private String text;
   // getter and setter
 
   public String nextpage (){
       return "page2";
   }
}

As scope is not specified, the default scope is request.

JSF page (page1.xhtml):

<h :form>
   </h><h :panelGrid>
	<h :outputText value="Text:" />
	<h :inputText value="#{bean.text}" />
	<h :commandButton action="#{bean.nextpage}" value="Click" />
   </h>

Read more »

Learning JSF2: Page params and page actions

Learning JSF 2 series continues with page parameters and page actions. Read other Learning JSF 2 articles.

If you worked with JSF 1.2, you know that calling a page action wasn’t simple. A page action is useful when you request a page for the first time (GET request) and would like to prepare some data to be rendered on a view (page). Of course there are some workarounds, one of them is to use @PostConstruct method inside the bean or even create a phase listener. Both could work but developers desired a more robust, and out of the box solution similar to what Seam 2 provides. Read more »

Will review JSF 2.0 Cookbook

I was offered to review JSF 2.0 Cookbook from Packt Publishing and gladly accepted. Once I’m done reading the book, you can expect a detailed review. A few months ago I reviewed JSF 1.2 Components book from Packt Publishing.

Learning JSF2: Ajax in JSF – using f:ajax tag

This is a third post in Learning JSF 2 series. The first one on Managed Beans can be found here and second one on navigation can be found here

As you probably know JSF 2 is a major upgrade over JSF 1.2. One of the major additions to this version of JSF is standard Ajax support. This article covers Ajax features in JSF 2. If you are familiar with RichFaces and specifically the a4j:support tag then learning how to use Ajax features in JSF 2 is going to be very easy. Many concepts and features are being carried over from RichFaces.  Let’s start. 
Read more »

JSF, RichFaces, CDI, JBoss Tools workshop in Minsk, Belarus

Several members of the RichFaces and JBoss Tools teams will be presenting at the Modern Java Technologies Workshop in Minsk, Belarus. From the RichFaces team Nick Belaevski and Ilya Shaikovsky will be discussing Java Server Faces 2.0, and then two topics on RichFaces 3.3.X and 4.0.X.

More information (more information in Russian).

To register, send an email to conference@exadel.com

RichFaces-like Ajax features in JSF 2

I attended David Geary’s talk on Killer Web Apps with JSF 2 Ajax at JSF Summit where he demonstrated Ajax features in JSF 2. As you start with JSF 2, you will notice that many Ajax features in JSF 2 are very similar to what RichFaces has been providing for a number of years now.

RichFaces 4 will be based on JSF 2 and will provide some interesting advanced features on top of standard JSF 2 Ajax. Some features are advanced queues, advanced rendering features and tags such as a4j:poll, a4j:status and more. Here is a blog entry that demonstrates Ajax features in RichFaces 3.3.x, JSF 2 and RichFaces 4.

Nick Belaevski newest member of the JSF 2.0 Expert Group

As reported here, Nick Belaevski is the newest member to join JSF 2 Expert Group from Exadel. Nick is Exadel’s lead developer for RichFaces project. On the Exadel side, Nick joins Alexander Smirnov who has been a member for a long time.

Congratulations, Nick!

Article: JSF 2 – Seam’s Other Avenue to Standardization

Great article by Dan Allan on how Seam and RichFaces (in particular Ajax4jsf) helped shape JSF 2.

Learning JSF2: Navigation

This is a second post in Learning JSF 2 series. The first one on Managed Beans can be found here.

Before I start, thanks to Nick Belaevski (RichFaces Team Lead – Exadel) for reviewing this posting.

In JSF 1.2 all navigation rules are placed in JSF configuration file. Although you can still places navigation rules inside JSF configuration file, JSF 2 upgrades navigation by introducing implicit navigation and conditional navigation.

Implicit navigation

In JSF 1.2, navigating from one page to another required something like this:

<navigation-rule>
   <from-view-id>page1.xhtml</from-view-id>
   <navigation-case>
       <from-outcome>next</from-outcome>
       <to-view-id>/page2.xhtml</to-view-id>
   </navigation-case>
</navigation-rule>

JSF 2 now supports implicit navigation where you don’t need to define a navigation rules inside JSF configuration file. You can do this:

<h:commandButton action="page2" value="Submit" />

JSF will try to find a view named page2.xhtml in the current directory.

The following will also work:

<h:commandButton action="page2.xhtml" value="Submit" />

or

<h:commandButton action="page2.jsf" value="Submit" />

Note: this is assuming that JSF servlet is mapped to .jsf.

or using the new h:link (or h:button) tags in JSF 2 (I’ll cover these tags in a separate posting):

<h:button outcome="page2" value="Go There"/>

Implicit navigation can also be used from within an action method:

public String next () {
   return "page2";
}

The following will also work:

public String next () {
   return "page2.jsf";
}
public String next () {
   return "page2.xhtml";
}

All examples above implied that both pages (page1.xhtml and page2.xhtml) are in the same directory (notice there is no / before page name). If pages are in different directories, then full path has to be used:

<h:commandButton action="/shopping/page2" value="Submit" />

or

public String next () {
   return "/shopping/page2" ;
}

Conditional navigation

In JSF 1.2, methods in managed beans would return arbitrary string values which are passed into the navigation. Navigation couldn’t use application state to help determine what page to select. The most you could is something like this, you could check what button/link was clicked in addition to using the outcome:

<navigation-rule>
   <from-view-id>/pages/course.xhtml</from-view-id>
   <navigation-case>
      <from-action>#{bean.register}</from-action>
      <from-outcome>success</from-outcome>
      <to-view-id>/pages/registered.xhtml</to-view-id>
   </navigation-case>
</navigation-rule>

In JSF 2, you can now do this:

<navigation-rule>
   <from-view-id>/pages/course.xhtml</from-view-id>
   <navigation-case>
      <from-action>#{bean.register}</from-action>
      <if>#{bean.prerequisiteCompleted}</if>
      <to-view-id>/pages/registered.xhtml</to-view-id>
  </navigation-case>
  <navigation-case>
   <from-action>#{bean.register}</from-action>
   <if>#{bean.advisingHold}</if>
   <to-view-id>/pages/scheduleAdvisingSession.xhtml</to-view-id>
  </navigation-case>
  <navigation-case>
   <from-action>#{bean.register}</from-action>
   <if>#{not bean.payment}</if>
   <to-view-id>/pages/payForCourse.xhtml</to-view-id>
  </navigation-case>
</navigation-rule>

When #{bean.register} action is invoked, based on .. condition (evaluates to true/false) in each case, it’s possible to navigate to three different pages. This allows to use application state to determine where to navigate. It’s not longer necessary to have model objects return arbitrary strings and thus could eliminate having your back-end know anything about navigation.

Forward/Redirect

When navigating to another page, both JSF 1.2 and JSF 2 perform a forward (default behavior) to the new page (Seam, for example does a redirect by default). Because it’s a server forward (the browser is not aware that we are displaying a different page), you might have noticed that the page address in the URL is always one behind.

If defining navigation rules in JSF configuration file, then the same tag is used in JSF 1.2 and JSF 2:

<navigation-rule>
   <from-view-id>/bar/enter.xhtml</from-view-id>
      <navigation-case>
	<from-outcome>enterBar</from-outcome>
        <to-view-id>/bar/welcome.xhtml</to-view-id>
        <redirect/>
    </navigation-case>
</navigation-rule>

When using implicit navigation in JSF2, redirect is setup using faces-redirect=true request parameter:

<h:commandLink  action="/bar/welcome?faces-redirect=true" value="Go to page 5"/>

If returning an outcome from action method:

public String enter () {
   return "/bar/welcome?faces-redirect=true";
}

Using EL in to-view-id

You can also use EL in :

<navigation-rule>
   <from-view-id>/el/page1.xhtml</from-view-id>
   <navigation-case>
      <from-action>#{bean.navigate}</from-action>
      <from-outcome>success</from-outcome>
      <to-view-id>#{bean.page}</to-view-id>	
   </navigation-case>
</navigation-rule>

In the managed bean:

…
private String page;
 
public String getPage () {
    return this.page;
}
public String navigate () {
   this.page = "/el/page3";
   return "success";
}
…

A topic closely related to navigation is page parameters and how they are propagated, I will cover that in another posting.

Finally, one thing to be aware of. Suppose you have the following rule:

<navigation-rule>
   <from-view-id>/purchase.xhtml</from-view-id>
   <navigation-case>
      <from-action>#{bean.purchase}</from-action>
      <if>#{not bean.creditCardExpired}</if>
     <to-view-id>/confirmation.xhtml</to-view-id>
   </navigation-case>
</navigation-rule>

In managed bean:

public String purchase () {
   ...
   return "confirmation";
}

Suppose creditCardExpired evaluates to true and thus making condition false. In such case you would think that navigation shouldn’t take place. However, you still navigate to confirmation.xhtml because implicit navigation is used. First, the above case is matched but not selected as .. evaluates to false. Navigation continues to look for a match and because purchase() method returned a string value of “confirmation” is used by implicit navigation which matches a page with such name. Implicit navigation is used last.

Ajax in RichFaces 3.3, JSF 2 and RichFaces 4

During my RichFaces session at JBoss World 2009, I showed three small examples of using Ajax with RichFaces 3.3, JSF 2, and RichFaces 4. I thougth it would be a good idea to show you the difference or more correct the similarities between the three. I will be blogging more about RichFaces 4 and JSF 2 so this is just a quick introduction.

I will show a small “Echo” application. There is one input field and as as you type, the input is echoed on the next line. On another line, the length of the string entered is counted. It looks like this:

screenshot_036

As you type, an Ajax request is sent to the server. We then do partial view rendering by specifying what components (text, count) to render back to the browser.

RichFaces 3.3

<h:form>
   <h:panelGrid columns="2">
      <h:outputText value="Text:" />
      <h:inputText value="#{echoBean.text}" >
         <a4j:support event="onkeyup" action="#{echoBean.countAction}"
  	    reRender="text, count"/>
  	 </h:inputText>
      <h:outputText value="Echo:" />
      <h:outputText id="text" value="#{echoBean.text}" />
      <h:outputText value="Count:" />
      <h:outputText id="count" value="#{echoBean.count}" />
   </h:panelGrid>
</h:form>

Managed bean:

public class EchoBean {
   private String text; // getter and setter
   private Integer count;  // getter and setter
 
   public void countAction() {
	count = text.length();
   }
   ...
}

Bean is registered in JSF configuration file (not shown).

JSF 2

<h:form>
   <h:panelGrid columns="2">
      <h:outputText value="Text:" />
      <h:inputText value="#{echoBean.text}" >
         <f:ajax event="keyup" execute="@form" render="text count" 
  		       listener="#{echoBean.countListener}"/>
      </h:inputText>
      <h:outputText value="Echo:" />
      <h:outputText id="text" value="#{echoBean.text}" />
      <h:outputText value="Count:" />
      <h:outputText id="count" value="#{echoBean.count}" />
   </h:panelGrid>
</h:form>

Managed bean looks slightly different as instead of an action (see example above) we use a special Ajax listener:

@ManagedBean(name="echoBean")
@RequestScoped
public class EchoBean {
   private String text;
   private Integer count;
 
   public void countListener (AjaxBehaviorEvent event) {
	count = text.length();
   }
}

RichFaces 4.0

<h:form>
    <h:panelGrid columns="2">
       <h:outputText value="Text:" />
       <h:inputText value="#{echoBean.text}" >
          <a4j:ajax event="keyup" render="text,count" 
  			listener="#{echoBean.countListener}"/>
  	   </h:inputText>
  	<h:outputText value="Echo:" />
  	<h:outputText id="text" value="#{echoBean.text}" />
       <h:outputText value="Count:" />
       <h:outputText id="count" value="#{echoBean.count}" />
   </h:panelGrid>
</h:form>

Managed bean is same as in JSF 2.

  1. Ajax features in JS2 are very similar to what’s been available in RichFaces for a couple of year. The JSF standard continues to evolve by assimilating the best ideas in the community into the standard. A perfect example is how the Ajax support in JSF 2.0 almost matches that of RichFaces.
  2. a4j:support has been replaced with a4j:ajax in RichFaces 4
  3. a4j:ajax has all the functionality of standard JSF 2 Ajax tag with many additional features to give you more flexibility and power available only in RichFaces.
  4. For example, features such as client queues, more control on deciding what to process and render, defining parts of a view to always render and much much more.

Next Page »