Friday, August 30, 2013

JSF 2.x Tip of the Day: FacesMessage Severity Differences Between Mojarra and MyFaces

Introduction

We encountered an inconsistency between MyFaces and Mojarra that I was surprised was not addressed a long time ago. The issue has to do with the ordinal values assigned to the FacesMessage.Severity. Mojarra uses a zero(0) based level of Severity and MyFaces uses a one(1) based Severity level. As a result, we were trying to use a <rich:notifyMessages/> component with, as you can expect, some unexpected results.

One of the items I always preach is to code to the API. If you code to the API, then you can switch out the implementations should the need occur. This is a best practice, but can be undermined by little subtleties like this. Please don't get me wrong, both Mojarra and MyFaces are great implementations. It is these fine differences that should be consistent that we need to work on to make sure that we are consistent, and that the dream is real; switching implementations will not be painful.

RichFaces is a good framework, and folks like Brian Leathem take personal pride in making it a good implementation to run on top of either Mojarra, or MyFaces. I was really surprised by my discovery of an issue with <rich:notifyMessages/> since the <rich:messages/> works correctly. The problem is focused on the ordinal value I mentioned. I opened a JIRA issue with both MyFaces and RichFaces around the ordinal issue. Please see the references below for details.

However, I needed a solution not just report an issue. So I came up with a 10¢ solution based on some work I did at home last night, and a great suggestion by one of my team. I wanted to publish an article, a complaint, and a solution that others may need. These work arounds tend to become more common when doing cross-platform development, and sharing is paramount.

Problem

The RichFaces <rich:notifyMessages/> does not work consistently across JSF implementations based on Severity ordinal values.

Solution

Implement a method that checks the FacesMessage.Severity ordinal values, and change icons and CSS to correct the differences between implementations. We can accomplish this using CSS, and Expression Language (EL) combined with a page backing bean. In this case, I use a simple page backing bean, but it could be converted to a custom EL function.

The code for this example can be found here: myfaces-rf-example

default.css



iconURL()


This simple solution allows us to check to see if the implementation starts at 0, or 1 and changes the icons and CSS.

References

Wednesday, August 28, 2013

JSF 2.x Tip of the Day: Guice ELResolver using SLF4J Logging

Introduction

I was recently tasked with looking at some mechanisms to control logging in our JSF applications. This included a number of proof of concept ideas to see which Dependency Injection (DI) mechanisms we could use. We are currently using CDI (Weld), and OpenWebbeans in our applications. I had previously used Guice for doing DI in some other applications especially in Java SE which I found it very easy to use.

As I looked around, I found that I could not find a good example of how to use Guice with JSF 2.x. There were a number of articles from over the years for using Guice with JSF 1.2 primarily, but nothing that used some of the great enhancements to JSF 2. I also found very little on how to implement FacesWrapper to wrap ApplicationFactory, Application, and ELResolver. The exception being ELResolver code that you can find in OmniFaces.

Implementation

The implementation uses a number of techniques to inject our custom ELResolver. First we will use a FacesWrapper to wrap the ApplicationFactory. Our implementation will return a custom ApplicationWrapper implementation, that will return a custom FacesWrapper for our ELResolver. This arrangement may seem complex, but separates the concerns to allow us to refactor them as necessary.

The code for this project can be found here: jsf-guice-logger-integration

GuiceServletContextListenerImpl.java


FacesApplicationFactoryWrapper.java


FacesApplicationWrapper.java


GuiceELResolverWrapper.java


faces-config.xml

There are additional classes that do the logging that can be found in the project. The primary interest here is how to get an ELResolver implementation that will resolve our Guice injections. I hope this demonstration of JSF 2.x wrappers can show you how easy it is to implement custom wrappers including a custom ELResolver.

References

Tuesday, August 06, 2013

JSF 2.x Tip of the Day: jsf.js AJAX onEvent() and onError() Examples

I was looking for some information on what I could do with the jsf.js AJAX scripts in JSF. Specifically, I was wondering if I could do some event handling, and how it should be accomplished. I was surprised that there really was not a complete example that I could find. I did find some blog posts from Jim Driscoll and some comments on stackoverflow by +Bauke Scholtz which show a partial solution, but nothing complete.

I decided to combine the good parts of Jim's blog post with some of the goodies from +Bauke Scholtz to create a complete example. In this example, I use a solution from Jim to demonstrate the events that are returned from the onEvent() and onError() listeners.  Along with a common request... A spinner for AJAX requests.

Once you download, and run the code. You will see a spinner while the AJAX request is processing. In my case, I use a Thread.sleep(2000); to cause the spinner to display for a little while.

The code for project can be found here: jsf-ajax-demo

index.xhtml



IndexBean.java



References

This is based on the primarily on the work published by Jim Driscoll and Bauke Scholz. This is just a more complete example  of what they mentioned in their articles.

Popular Posts