Source Allies Blog » JSF

Rendering Global t:messages After Redirect

Max Kuipers — Mon, 08 Mar 2010 19:24:46 +0000

A common problem when working with JSF is getting global info messages via or to display messages set in the previous request when you have a in your faces-config for a particular page You will not see your that are set on the previous page.

The Problem

For instance, say you have two pages – page1.xhtml and page2.xhtml. In your faces-config.xml, you will have 2 entries.

>
	>page1>
	>/pages/page1.xhtml>
	/>
>
 
>
	>page2>
	>/pages/page2.xhtml>
	/>
>

Let’s say page1Bean is called in page1 and you want it to display messages in page2. So your bean would have something like this:

public class page1Bean {
	...
	public String page1Action{
		...
		/** Add message */
		FacesMessage facesMessage = new FacesMessage();
		...
		FacesContext.getCurrentInstance().addMessage(null, facesMessage);
		...
		return "page2";
	}
	...
}

Your page2.xhtml has like the following somewhere in it.

One would expect that this would display the message on the next page, however these messages are request scoped and so are not available in this second request and you do not see your message unless you remove the on page2.

Fortunately, there is a nifty and quick solution. Basically, it is a phase listener that saves the messages from the previous request and then restores them just before the RENDER_RESPONSE phase of the second request.

The Solution

To solve the problem, save the following class into some package where your faces-config will be able to access it

package com.myproject.web.jsf.phaselistener;
 
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
 
import javax.faces.application.FacesMessage;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
 
/**
 * Enables messages to be rendered on different pages from which they were set.
 * To produce this behaviour, this class acts as a PhaseListener.
 *
 * This is performed by moving the FacesMessage objects:
 *
	After each phase where messages may be added, this moves the messages from
 * the page-scoped FacesContext to the session-scoped session map.
 *
	Before messages are rendered, this moves the messages from the session-scoped
 * session map back to the page-scoped FacesContext.
 *
 * Only messages that are not associated with a particular component are ever
 * moved. These are the only messages that can be rendered on a page that is different
 * from where they originated.
 *
 * To enable this behaviour, add a lifecycle block to your
 * faces-config.xml file. That block should contain a single phase-listener
 * block containing the fully-qualified classname of this file.
 *
 * EDIT: This code was minimally modified by Max Kuipers to address some of the Java 1.6
 * compiler warnings.  All code was originally written by Jesse Wilson.
 *
 * @author Jesse Wilson
 * @author Max Kuipers
 */
 
public class MessageHandler implements PhaseListener {
	private static final long serialVersionUID = 1L;
 
	/**
	 * a name to save messages in the session under
	 */
	private static final String sessionToken = "MULTI_PAGE_MESSAGES_SUPPORT";
 
	/**
	 * Return the identifier of the request processing phase during which this
	 * listener is interested in processing PhaseEvent events.
	 */
	public PhaseId getPhaseId() {
		return PhaseId.ANY_PHASE;
	}
 
	/**
	 * Handle a notification that the processing for a particular phase of the
	 * request processing lifecycle is about to begin.
	 */
	public void beforePhase(PhaseEvent event) {
 
		if(event.getPhaseId() == PhaseId.RENDER_RESPONSE) {
			FacesContext facesContext = event.getFacesContext();
			restoreMessages(facesContext);
		}
	}
 
	/**
	 * Handle a notification that the processing for a particular phase has just
	 * been completed.
	 */
	public void afterPhase(PhaseEvent event) {
 
		if(event.getPhaseId() == PhaseId.APPLY_REQUEST_VALUES ||
				event.getPhaseId() == PhaseId.PROCESS_VALIDATIONS ||
				event.getPhaseId() == PhaseId.INVOKE_APPLICATION) {
 
			FacesContext facesContext = event.getFacesContext();
			saveMessages(facesContext);
		}
 
	}
 
	/**
	 * Remove the messages that are not associated with any particular component
	 * from the faces context and store them to the user's session.
	 *
	 * @return the number of removed messages.
	 */
	private int saveMessages(FacesContext facesContext) {
		// remove messages from the context
		List messages = new ArrayList();
		for(Iterator i = facesContext.getMessages(null); i.hasNext(); ) {
			messages.add(i.next());
			i.remove();
		}
		// store them in the session
		if(messages.size() == 0) {
			return 0;
		}
		Map sessionMap = facesContext.getExternalContext().getSessionMap();
		// if there already are messages
		@SuppressWarnings("unchecked")
		List existingMessages = (List) sessionMap.get(sessionToken);
		if(existingMessages != null) {
			existingMessages.addAll(messages);
		}
		else {
			sessionMap.put(sessionToken, messages); // if these are the first messages
		}
 
		return messages.size();
	}
 
	/**
	 * Remove the messages that are not associated with any particular component
	 * from the user's session and add them to the faces context.
	 *
	 * @return the number of removed messages.
	 */
	private int restoreMessages(FacesContext facesContext) {
		// remove messages from the session
		Map sessionMap = facesContext.getExternalContext().getSessionMap();
		@SuppressWarnings("unchecked")
		List messages = (List)sessionMap.remove(sessionToken);
		// store them in the context
		if(messages == null) {
			return 0;
		}
		int restoredCount = messages.size();
		for(Iterator i = messages.iterator(); i.hasNext(); ) {
			facesContext.addMessage(null, i.next());
		}
 
		return restoredCount;
	}
}

And then add something like the following in your faces-config.xml. Be sure to replace the example package location with your own.

>
	>com.myproject.web.jsf.phaselistener.MessageHandler>
>

The forum post that documented this solution is here.

Java EE 6 and Scala

Zach Cox — Mon, 22 Feb 2010 17:36:31 +0000

Last weekend while pondering the question “Is Scala ready for the enterprise?” I decided to write a simple Java EE 6 app entirely in Scala, without using any Java. I had three main reasons for doing this: one was just to see how easy/difficult it would be to write everything in Scala (it was easy). Another was to document the process for others journeying down the same road (the entire project is on github). Finally, I wanted to identify advantages of using Scala instead of Java that are specific to Java EE apps (I found several).

Background

The specific app I created was an adaptation of the Books example from Chapter 10 of Beginning Java™ EE 6 Platform with GlassFish™ 3. It’s a simple web app that displays a list of books in a database and lets you add new books. Although it’s a pretty trivial app, it does touch on several important Java EE 6 technologies: JPA 2.0, EJB 3.1 and JSF 2.0.

Results

As a baseline, I first created the example from the Book using Java (and put it on github). The three Java classes are mostly identical to the book: Book.java, BookEjb.java and BookController.java. Aside from those, I refactored common elements of the two JSF views into a template, included the Blueprint CSS framework and created a better Maven pom.xml.

Next I rewrote the Java parts in Scala (and put it on github). Initially I did a one-to-one mapping of the Java classes to their Scala counterparts. Once that was complete I did a bit of refactoring to Book.scala and BookEjb.scala, so the versions you’ll see on github now look a bit different. During this process I did use some hints from a few other related blog posts.

JPA

First up, here’s Book.java:

package com.sourceallies.model;
 
import javax.persistence.*;
 
@Entity
@NamedQuery(name = Book.FindAllBooks, query = "SELECT b FROM Book b")
public class Book {
	public static final String FindAllBooks = "findAllBooks";
 
	@Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	private Long id;
 
	@Column(nullable = false)
	private String title;
 
	private Float price;
 
	@Column(length = 2000)
	private String description;
 
	private String isbn;
	private Integer nbOfPage;
	private Boolean illustrations;
 
	public Long getId() {
		return id;
	}
 
	public void setId(Long id) {
		this.id = id;
	}
 
	public String getTitle() {
		return title;
	}
 
	public void setTitle(String title) {
		this.title = title;
	}
 
	public Float getPrice() {
		return price;
	}
 
	public void setPrice(Float price) {
		this.price = price;
	}
 
	public String getDescription() {
		return description;
	}
 
	public void setDescription(String description) {
		this.description = description;
	}
 
	public String getIsbn() {
		return isbn;
	}
 
	public void setIsbn(String isbn) {
		this.isbn = isbn;
	}
 
	public Integer getNbOfPage() {
		return nbOfPage;
	}
 
	public void setNbOfPage(Integer nbOfPage) {
		this.nbOfPage = nbOfPage;
	}
 
	public Boolean getIllustrations() {
		return illustrations;
	}
 
	public void setIllustrations(Boolean illustrations) {
		this.illustrations = illustrations;
	}
 
	public static String getFindallbooks() {
		return FindAllBooks;
	}
}

The Java version has 58 lines of completely useless getters & setters. You need at least 9 lines per field and more for additional annotations. IDEs like Eclipse can generate these getters/setters for you, but they still take up space and must be maintained over time.

Now let’s look at the Book entity in Scala:

package com.sourceallies.model
 
import javax.persistence._
import scala.reflect._
 
@Entity
@NamedQuery{val name = "findAllBook", val query = "SELECT b FROM Book b"}
class Book extends Id with Description {
  @Column{val nullable = false}
  @BeanProperty
  var title: String = _
 
  @BeanProperty
  var price: Float = _
 
  @BeanProperty
  var isbn: String = _
 
  @BeanProperty
  var nbOfPage: Int = _
 
  @BeanProperty
  var illustrations: Boolean = _
}
 
/** Defines an id field for entities to use as a primary key. */
trait Id {
  @javax.persistence.Id
  @GeneratedValue{val strategy = GenerationType.IDENTITY}
  @BeanProperty
  var id: Long = _
}
 
/** Defines a description field for entities. */
trait Description {
  @Column{val length = 2000}
  @BeanProperty
  var description: String = _
}

In the code base these are actually three separate files: Book.scala, Id.scala and Description.scala, I just included them all in one place here for convenience.

The Scala version needs only two lines per field: one for the @BeanProperty annotation to generate getters/setters in the compiled class and one to declare the field itself. This is seven lines less than the Java version per field.

Fields are declared as vars so they are public by default, mutable and every var that is a non-private member of some object implicitly defines a getter and a setter method with it. So “var x” defines a getter just named “x” and a setter named “x_=”. This lets you get the field using object.x and set it using object.x = y.

If JPA supported Scala-style accessors & mutators, we’d be done, but it requires the use of get/set methods. This is why we use @BeanProperty on each field. This instructs the Scala compiler to generate Java-style get/set methods in the compiled class file so it looks just like a Java entity to JPA.

You may also be wondering why each field is assigned a value of _ in its declaration. This is just the default value in Scala, just like omitting an initializer in Java: 0 for numeric types, false for booleans, and null for reference types.

The annotations also look a bit different; in Java they’re @Column(nullable = false) but in Scala are @Column{val nullable = false}. This is just how you do it in Scala.

I also pulled the id and description fields out into their own traits. This makes the entity class shorter and makes common fields reusable and more consistent across entities. I could have pulled all fields out into their own traits, but in practice there’s probably a limit to how much you’d want to do this, some fields will be specific to a single entity class and not reusable.

EJB

Now let’s look at BookEjb.java:

package com.sourceallies.ejb;
 
import java.util.*;
 
import javax.ejb.*;
import javax.persistence.*;
 
import com.sourceallies.model.*;
 
@Stateless
public class BookEjb {
	@PersistenceContext(unitName = "book")
	private EntityManager manager;
 
	@SuppressWarnings("unchecked")
	public List<Book> findBooks() {
		return manager.createNamedQuery(Book.FindAllBooks).getResultList();
	}
 
	public Book createBook(Book book) {
		manager.persist(book);
		return book;
	}
}

The Java version is very simple: it basically just provides two Book-specific CRUD methods using a JPA EntityManager.

And here is the Scala version:

package com.sourceallies.ejb
 
import javax.ejb._
import javax.persistence._
import com.sourceallies.model._
 
@Stateless
@LocalBean
class BookEjb extends CrudEjb[Book]
 
/** Provides basic CRUD support using an injected JPA entity manager. */
trait CrudEjb[E] {
  @PersistenceContext
  protected var manager: EntityManager = _
 
  def create(entity: E): E = {
    manager persist entity
    entity
  }
 
  def readAll()(implicit m: Manifest[E]) = manager createNamedQuery ("findAll" + m.erasure.getSimpleName) getResultList
 
  def read(id: Long)(implicit manifest: Manifest[E]): E = manager.find(manifest.erasure, id).asInstanceOf[E]
 
  def update(entity: E): E = manager merge entity
 
  def delete(entity: E) { manager remove entity }
}

Again, these are two separate files in the actual code base: BookEjb.scala and CrudEjb.scala.

In the Scala version I created the CrudEjb trait that provides full CRUD support for any JPA entity, so the concrete EJB can be defined simply as BookEjb extends CrudEjb[Book]. In several places we need the Class object of the entity, which is difficult to obtain due to Java’s erasure of generic types at runtime. Scala’s Manifests are a great solution to this problem.

The Scala version requires the @LocalBean annotation while the Java version does not (not sure why). Also the EntityManager is defined as a var without the Java-style getters and setters. The container is able to inject the EntityManager using the Scala-style mutator (bean.manager = x) but it does log an error about it not having a set method.

JSF

And now the BookController.java:

package com.sourceallies.controller;
 
import java.util.*;
 
import javax.ejb.*;
import javax.faces.bean.*;
 
import com.sourceallies.ejb.*;
import com.sourceallies.model.*;
 
@ManagedBean
@RequestScoped
public class BookController {
	@EJB
	private BookEjb ejb;
	private Book book;
	private List<Book> bookList;
 
	public Book getBook() {
		if (book == null)
			book = new Book();
		return book;
	}
 
	public void setBook(Book book) {
		this.book = book;
	}
 
	public List<Book> getBookList() {
		if (bookList == null)
			bookList = ejb.findBooks();
		return bookList;
	}
 
	public void setBookList(List<Book> bookList) {
		this.bookList = bookList;
	}
 
	public String doNew() {
		return "newBook.xhtml";
	}
 
	public String doCreateBook() {
		book = ejb.createBook(book);
		bookList = ejb.findBooks();
		return "listBooks.xhtml";
	}
}

This Java version is simply a Book-specific CRUD wrapper around BookEjb, and provides Book and List objects to the JSF views.

And finally, BookController.scala:

package com.sourceallies.controller
 
import javax.ejb._
import javax.faces.bean._
 
import com.sourceallies.model._
import com.sourceallies.ejb._
 
@ManagedBean
@RequestScoped
class BookController {
  @EJB
  private var ejb: BookEjb = _
 
  private val book = new Book
 
  def getBook = book
 
  def getBookList = ejb.readAll
 
  def doNew() = "newBook.xhtml"
 
  def doCreateBook() = {
    ejb create book
    "listBooks.xhtml"
  }
}

The Scala version is basically just the Java version converted to Scala, no major changes, just looks a bit cleaner due to Scala’s concise syntax. As with the EJB, we get an error logged about not having a set method for injecting BookEjb, but the container does actually inject an instance properly.

Conclusion

Even though this was a simple example, I think it shows a few advantages of using Scala instead of Java in Java EE apps. You can forget about useless getters/setters in JPA entity classes, use traits to reuse common JPA entity field definitions and mixin common behavior in EJBs (example: BookEjb could also mixin Logging trait and other traits). And advanced Scala features like Manifests help you write better code faster.

This example only scratched the surface of what Scala can do, and didn’t even use things like closures, case classes, pattern matching or Scala’s functional programming capabilities (using Scala collections of JPA entities would help a lot).

Keep your dataTable clean with a custom popup

David Casleton — Wed, 13 Jan 2010 14:05:57 +0000

The basic idea is to output some data to a user in a table and allow them to take an action on each row individually. A fairly straightforward solution is to create a separate page to link to, passing the necessary row information along. If the action is simple enough, like a single checkbox, you could just embed the necessary component(s) in each row of the table. Too many components, however, can bloat the table and make the UI cumbersome to the user. Instead we can create a popup window to overlay our page, containing whatever components are needed, and activate it by a link embedded in our table. Passing the row information is a little trickier, but the result is a cleaner interface and a better user experience.

The example implementation below is done using Java with JSF, a little JavaScript, a little jQuery, and some CSS. The tag libraries being referenced are:

xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:t="http://myfaces.apache.org/tomahawk"

The page is constructed using two separate forms, one for the main components of the page, including the datatable, and the other for the popup. A little JavaScript and jQuery are used to show/hide the popup form and pass around the pertinent row information. Some CSS is used to shadow the main page components while the popup is active.

Our simple main form is:

 id="someForm">
 
	 id="actionDetailsDiv" styleClass="info" 
			rendered="#{not empty myAction.actionDetails}">
		 escape="false" value="#{myAction.actionDetails}" />
	>
 
	 var="currentRow" 
			rowIndexVar="rowNum" 
			value="#{myAction.myData}" >
		>
			 name="header">
				 value="row" />
			>
			#{rowNum}
		>
 
		>
			 name="header">
				 value="some colummn" />
			>
			#{currentRow.someProperty}
		>
 
		>
			 name="header">
				 value="action links" />
			>
			 href="javascript:showHiddenForm('#{rowNum}')">action link>
		>
	>	
>

Here the row number (rowNum) has been passed to a piece of JS, but you could just as easily pass a property from the current row object. Also, actionDetails is a string on our backing action bean used to inform the user that the action has been taken on the appropriate data. This should be declared in the backing bean as an empty string and thus the containing div is not initially rendered.

Our hidden form is:

 id="hiddenForm">
	 id="backgroundDiv" class="fullscreen outer" />
 
	 id="foregroundDiv" class="centerPopup inner">
		>Action Heading>
 
		 id="hiddenInfo" forceId="true" />
 
 
		 value="Backing Action" actionListener="#{myAction.backingAction}"/>		
		 onclick="hideHiddenForm()" value="Cancel"/>
	>
>

To prove that the data in the hidden field is being populated correctly, change the inputHidden component to inputText.

The CSS referenced above is:

div.fullscreen {
	position:absolute;
	top:0;
	left:0;
	width:100%;
	height:100%;
}
 
div.centerPopup {
	position: fixed;
	top: 50%;
	left: 50%;
	height: 200px;
	width: 500px;
	overflow: auto;
	margin-top: -100px;
	margin-left: -250px;
}
 
div.outer {
	filter: alpha(opacity=50);
	-moz-opacity: 0.5;
	opacity: 0.5;
	background-color: #D8D8D8;
	z-index: 2000;
}
 
div.inner {
	background-color: #000000;
	z-index: 2001;
}
 
p.inner {
	color: white;
}
 
div.info {
    text-align: center;
    font-weight: bold;
    border-top: 1px solid;
    border-bottom: 1px solid;
}

Most of the CSS is pretty straightforward. The “outer” class is setup to make a div gray and transparent in most browsers and “centerPopup” creates a statically sized div in the middle of the screen. The crucial part of the CSS is the z-index used by the “inner” and “outer” classes. The higher the z-index, the higher on the stack the element is, thus to show the “inner” popup over the somewhat transparent “outer” fullscreen overlay, the popup’s z-index must be higher. Both z-indexes are set arbitrarily high to ensure other elements don’t interfere.

The JavaScript/jQuery to show and hide the hidden form is:

function hideHiddenForm() {
	$("#hiddenForm").hide();
}
 
function showHiddenForm(selection) {
	//set the value of the hidden field
	var thingy = document.getElementById("hiddenInfo");
	thingy.value=selection;
 
	$("#hiddenForm").show();
}
 
$(document).ready(function() {
	//initially hide the popup form
	hideHiddenForm();
});

Note showHiddenForm takes a single input and sets this as the value of the hiddenInfo element. Also, we need to hide the popup form when the page is first loaded.

In our backing bean (MyAction) the backingAction method needs to find the hidden field and do something with the value. Here the value is passed to the actionDetails property forcing actionDetailsDiv above the table to render when the page is rerendered. Typically we would actually act on the value instead of merely redisplaying it.

public void backingAction(ActionEvent event) {
	UIComponent link = (UIComponent) event.getSource();
	for (UIComponent divChild : link.getParent().getChildren()) {
		if (divChild.getAttributes().get("id").equals("hiddenInfo")) {
			String rowNum = (String) divChild.getAttributes().get("value");
			setActionDetails("Action taken on row " + rowNum);
			break;
		}
	}
}

The hidden form (popup) can become as complicated as you need and allows your main form to remain clean. If anyone knows an easier way to pull the value out of the hidden element, let me know.