In my case, I had two date selector components on my form, one for a start date/time and one for an end date/time for an event that was being scheduled. The rule I needed to validate was that the end date/time was later than the start date/time.

There are a few ways to implement validation like this, including but not limited to:

1. Build a custom component that renders selectors for both the start and end date/time, then validate as a unit. This actually is field-level validation and doesn’t truly address the form-level problem.
2. Implement a validator method on a managed bean that will evaluate the data submitted for multiple components.

I’ll address the second method in this HOWTO.

First, you’ll need to bind at least n-1 of the components that you want to validate to properties on your managed bean. The simplest way is to declare properties of type UIInput:

private UIInput startDateComponent;

public UIInput getStartDateComponent() {    return startDateComponent;}

public void setStartDateComponent(UIInput startDateComponent) {      this.startDateComponent = startDateComponent;}

and do the actual binding in the JSP:

<t:inputDate id="eventStart" value="#{orderForm.sampleInfo.requestedStartTime}"    type="both"    popupCalendar="true"    ampm="true" binding="#{dateValidationForm.startDateComponent}"/>

Next, you’ll implement the validation method, which can have any name you like, but must share the same signature as this example:

public void validateEndDate(FacesContext context, UIComponent toValidate, Object value) {    Date endDate = (Date) value;    Date startDate = (Date) getStartDateComponent().getLocalValue();

    if (startDate == null) {        context.addMessage(getStartDateComponent().getClientId(context),new FacesMessage("Please specify a valid date and time."));        throw new ValidatorException(new FacesMessage());    }

    long endTime = endDate.getTime();    long startTime = startDate.getTime();

    if (startTime >= endTime) {        addError("errors.batchOrder.invalidEndDate");        throw new ValidatorException(new FacesMessage("Event end must be later than event start."));    }}

And finally, you’ll bind the validation method to the last component in your subset of components that need to be validated together:

<t:inputDate id="eventEnd" value="#{orderForm.sampleInfo.requestedEndTime}" type="both" popupCalendar="true" ampm="true" validator="#{dateValidationForm.validateEndDate}"/>

To understand why I say n-1 components, think of the way the validation phase occurs in JSF. Data is bound to the components in the order that they occur in the JSF component tree, which just so happens to be the order in which they appear in the JSP source. Looking at the validateEndDate method, you’ll see that I only reference the startDateComponent from the binding, but I reference the endDate as the Object value reference that was passed into the method. This is why you only need to bind n-1 components, because you get the nth component from the method signature.

If you want to be more uniform and bind all of the components, you could create an extra dummy hidden value component and bind the validator method to it. You could then bind all of the components to your managed bean and access them all from the bindings rather than accessing one from the method signature.

The validateEndDate method itself is rather simple. First you access the data by getting the local value of each component (again, the endDate value is not accessed in this way – in fact, it hasn’t been bound yet because it must be validated first, and that’s what’s happening in this method!). You then apply the business rule. You’ll see that first I look to see if the startDate is null. I’m not sure why this is possible, but if the startDate was not submitting a good value on the FIRST submit, the local value was null. So, I catch that here. I add an error message to the startDateComponent and throw a ValidatorException. If the business rule is violated, throw a ValidatorException. (I’m also using the addError method provided by AppFuse to work w/ its message framework as well, but that is not necessary w/ all JSF apps).

Now, for the final problem I encountered. In Weblogic server, which we’re still using for the time being, if your session cannot be serialized then it deletes your entire session. Obviously this can cause major problems in any web app. To deal with this, ANY SESSION SCOPED MANAGED BEAN must be fully serializable, meaning it and any objects referenced in its state. Herein lies the problem for JSF. Instances of UIComponent (an ancestor of UIInput) are not serializable, so if we bind our components to UIInput fields on a session-scoped managed bean (the bean backing this form is an Order Form/Shopping Cart style bean), it will not be serializable and Weblogic will kick out your session.

To deal with this problem, realize that there is no reason that you can only have one managed bean backing a form. In fact, you can reference as many managed beans as you need. Since validation is done for each request, there is no need to manage any state there across multiple requests like we need to do with a shopping cart. So, why not declare an additional managed bean that is REQUEST SCOPED, and then put the bindings and validation method there. That is exactly what I did. Here is the entire bean:

public class DateValidationForm extends BasePage {

    private UIInput startDateComponent;

    public UIInput getStartDateComponent() {        return startDateComponent;    }

    public void setStartDateComponent(UIInput startDateComponent) {        this.startDateComponent = startDateComponent;    }

    public void validateEndDate(FacesContext context, UIComponent toValidate, Object value) {        Date endDate = (Date) value;        Date startDate = (Date) getStartDateComponent().getLocalValue();

        if (startDate == null) {            context.addMessage(getStartDateComponent().getClientId(context),new FacesMessage("Please specify a valid date and time."));            throw new ValidatorException(new FacesMessage());        }

        long endTime = endDate.getTime();        long startTime = startDate.getTime();

        if (startTime >= endTime) {            addError("errors.batchOrder.invalidEndDate");            throw new ValidatorException(new FacesMessage("Event end must be later than event start."));        }    }}

and the declaration in faces-config.xml:

<managed-bean>    <managed-bean-name>dateValidationForm</managed-bean-name>    <managed-bean-class>org.stjude.hc.srmcti.webapp.action.ordering.
DateValidationForm</managed-bean-class>    <managed-bean-scope>request</managed-bean-scope></managed-bean>

The added bonus is that you can reuse this bean across all forms where you need this behavior. My application happens to have 2 additional forms where I would have repeated this logic, so I just reference this bean there.

Enjoy!

The two sessions that I attended were:

- RubyTooling: State of the Art
- Using Ajax with POJC (Plain Old JavaServer Faces Components)

I attended the first session simply to get a little more detail on all of the hype surrounding Ruby tooling support in NetBeans 6. What I got was even more than I bargained for. The project leaders actually walked us through not only the features that were available, but how they were implemented. I had never really thought about the problems with providing code completion and refactoring with a dynamically-typed language. It was really cool to see the thought process that went into their solutions. I’d love to hear a similar discussion from the JetBrains guys, as the Ruby support in IntelliJ IDEA is quite good as well.

For me the second session was the best of the conference for me up until that point, and arguably it still is after attending Friday’s sessions. Craig McClanahan, of Struts fame, was the main speaker and was joined by his colleagues Matthew Bohm and Jayashri Visvanathan. What made this session so good for me was that they presented a problem – “How can I add Ajax behaviors to my JavaServer™ Faces technology based application, without throwing away my investment in existing component libraries?” – and then provided three different solutions to that problem – low, medium, and high level.

The low level consisted of simply using the HTML event pass-through attributes that are implemented by most standard JSF components (onClick, onBlur, etc.). One could use an existing JavaScript framework such as Dojo to send an XMLHttpRequest and then map that request to a Servlet or JSF handler using a technology such as Shale Remoting. The response could be sent back as JSON data which could then be transformed into the desired UI update.

The medium level consisted of actually extending existing JSF components and adding the desired Ajax behavior. Due to time constraints they didn’t cover this solution in detail, but they did provide a link to a detailed discussion in the Java BluePrints catalog: https://blueprints.dev.java.net/bpcatalog/ee5/ajax/extendingRenderFunctionality.html

The high level solutions addressed the following needs (copied directly from the slides):

● Partial page submit—gather up a particular set of
input element values, and send them to a bit of server
side business logic
● Partial page refresh—the business logic needs to
refresh the content of one or more subtrees of the
client side DOM
● Synchronization—the benefits of synchronizing the
server side state
● Don’t repeat yourself (DRY)—reuse existing
components and renderers for partial page updates

To address these issues, the speakers highlighted two add-on frameworks:

● Ajax4JSF (http://labs.jboss.com/portal/jbossajax4jsf)
● Dynamic Faces (https://jsf-extensions.dev.java.net/)

I was quite impressed with both of these frameworks. One of my colleagues is currently implementing Ajax behavior in a Facelets-based application using Ajax4JSF and he is quite happy with it. Dynamic Faces looked really awesome, especially its tooling support in NetBeans (actually I’m quite impressed with the overall JSF support in NetBeans – I’ll definitely be adding it to my tool belt). The highlight of the presentation was Matt’s video of him building an entire currency trading application in 28 minutes – except it was “fast-played” to finish in 3 1/2 minutes and set to techno music. Matt wowed us with his dancing abilities while we watched true RAD. The crowd went wild!

- Creating Amazing Web Interfaces with Ajax
- jMaki: Web 2.0 App Building Made Easy
- Fast, Beautiful, Easy: Pick Three – Building Web User Interfaces in the Java Programming Language with Google Web Toolkit
- Killer JavaScript Technology Frameworks for Java Platform Developers: An Exploration of Prototype, Script.aculo.us, and Rico

I have to say that I was rather impressed by what I saw.

The first talk was by Ben and Dion, the Ajaxian guys. It was an appropriate way to start, as they gave a quick history overview of Ajax. One nice point they made was that Ajax really isn’t about the acronym – it never was – it’s about building killer websites. Who cares what the actual technology behind it is. They discussed a couple of what they seemed to consider the better frameworks available – Dojo and ExtJS. They then explored some amazing up and coming features, including offline support and 2D client side graphics manipulation.

I was rather impressed with jMaki – in short it is a wrapper around many of the popular JavaScript frameworks available (Dojo, Yahoo UI, Script.aculo.us, Spry, Google), and makes them accessible to Java, PHP, and Ruby. It has excellent tool support in NetBeans and Eclipse. It provides protection from changes in the API’s of all of these projects – you can mix and match frameworks and only be concerned about one API – jMaki’s. It does the work of linking all of the widgets together and communicating amongst them and with the server side.

The GWT talk was easily my favorite of the day. I’m extremely impressed with what these guys have done. I hadn’t had much opportunity to look at GWT until now, and I really wish I had. I was initially skeptical about writing an entire application in Java and letting it generate HTML and JavaScript. I guess these guys knew that, because they’re development philosophy addresses my concerns quite nicely:

To radically improve the web experience for
users by enabling developers to use existing
Java tools to build no-compromise AJAX for
any modern browser

From what I can see, they deliver on their mission. They’ve optimized their code for speed and for browser specificity (e.g. from what I understand, if your client is using Firefox, you get Firefox optimized JavaScript, same for IE, etc.). You can use all of your favorite IDE features to build the code, including the debugger. I really want to try to make use of this toolkit in the near future.

The final talk was less informative for me, but only because I had experience with most of the technologies already. The killer part of this was how the speaker extended existing JSF components and added Script.aculo.us effects. It really made his version of Yahoo maps shine.

Ajax isn’t going anywhere but up. I just left yet another Ajax/JSF session, which for me was the best session of the conference so far. In a later entry I’ll tell you why.