Benny's Blog » JSF

Java generic paged lazy List with JSF/JPA example implementation

Benny Bottema — Wed, 22 Jul 2009 12:58:53 +0000

Here’s a list implementation I came up with to enable true paged data fetching completely transparent to any user. It works independent of persistence layers, such as JPA implementations etc.

download PagedList

Lazy loading with the PagedList

Originally I made the PagedList because I needed paged data fetching using JMS queues for a JSF Rich datatable and datascroller; a common problem in JSF but less commonly solved, even less documented and less still solved in an elegant way. Most people are able to solve this problem by using an OpenSessionInView antipattern (keeping Hibernate-oid session open until the view requests the lazy loaded data) but since I’m using JMS queue, this was not an option. I decided to circumvent the entire JSF to JMS queue integration by providing my data in a paging lazy list. It works beautifully.

public class PagedList extends AbstractList {

    private final QueryParameters queryParameters;

    private final PagedDataProvider pagedDataProvider;

    private final Map> fetchedPages;

    private final int dataSize;

    private final int pageSize;

    public PagedList(PagedDataProvider pagedDataProvider, QueryParameters queryParameters) {
        this.pagedDataProvider = pagedDataProvider;
        this.queryParameters = queryParameters;
        fetchedPages = new HashMap>();
        dataSize = pagedDataProvider.getDataSize();
        pageSize = pagedDataProvider.getPageSize();
    }

    public Dto get(int index) {
        int pageNr = (int) Math.floor(index / pageSize);
        if (fetchedPages.get(pageNr) == null) {
            fetchedPages.put(pageNr, pagedDataProvider.provide(pageNr, queryParameters));
        }
        return fetchedPages.get(pageNr).get(index % pageSize);
    }

    public int size() {
        return dataSize;
    }
}

It is different from Apache’s LazyList (and many other implementations) in that it relies on an external dataprovider to provide the dataset’s total size, pagesize and data provision itself. For example, using my lazy list version the size() method actually returns the total size of data potentially available, not just physically available in the list at the present. This way the list works completely transparent to its users. Also, there is no simple factory being passed in that creates dummy objects or something: actual remote data is being fecthed in pages by a data provider. Pages being fetched are independent of each other; when requesting page 5, page 1 through 4 are not need or fetched.

The PagedList works in combo with a PagedDataProvider interface that external dataproviders (some dao for example) could implement. So it has no dependencies whatsoever on some specific implementation. The paged data provider provides the total size of the dataset, the page size and pages of the dataset itself when needed.

Example implementation for JSF and JPA dao

Here’s an example implementation which ties a JSF Richfaces datatable to a JPA dao using a PagedList. I cut out the service layer, view handlers/controllers and whatnot for sake of simplicity.

...

/**
 * JPA dao which acts as paged data provider for the paged list.
 *
 * Relies on two JPA named queries specified on the Entity being fetched.
 *
 * @author Benny Bottema
 * @see PagedDataProvider
 */
public class AppleJPADao implements AppleDao, PagedDataProvider {

    // entitymanager stuff omitted for example (real world: injected by Spring)

    private static final int PAGESIZE = 50;

    /**
     * @see AppleDao#getAllApples(String, String)
     */
    public List getAllApples(String type, String quality) {
        // optional query parameters: can be null
        AppleQueryParameters params = new AppleQueryParameters();
        params.setAppleType(type);
        params.setAppleQuality(quality);
        return new PagedList(this, params);
    }

    /**
     * @see PagedDataProvider#provide(int, Object)
     */
    public List provide(int page, AppleQueryParameters queryCriteria) {
        Query query = entityManager.createNamedQuery("Apple.findAll");
        query.setParameter("appleType", queryCriteria.getAppleType());
        query.setParameter("appleQuality", queryCriteria.getAppleQuality());
        // JPA's paging mechanism
        query.setFirstResult(PAGESIZE * page);
        query.setMaxResults(PAGESIZE);
        return (List) query.getResultList();
    }

    /**
     * @see PagedDataProvider#getDataSize()
     */
    public int getDataSize() {
        Query countQuery = entityManager.createNamedQuery("Apple.count");
        return ((Long) countQuery.getSingleResult()).intValue();
    }

    /**
     * @see PagedDataProvider#provide()
     */
    public int getPageSize() {
        return PAGESIZE;
    }
}

Known issues

So far there is only one known issue, which is more of a problem with lazy loading in general: synchronizing the lazy loading list with the remote dataset to avoid becoming stale when changes happen to the dataset. Example: when the dataset changes, the size of the list is not being updated and the get() method may try to fetch wrong or even unavailable data throwing an exception. Since I’m using the paged list in a limited way, I’ve not yet encountered this problem.

One way would be to solve this problem for the Rich datable and datascroller specifically is to have a a4j poll component that listens for dataset changes on the server and refreshes the entire datatable as necessary. Just thinking out loud here…

trackback

JSF is a diamond in the rough, you just need to make it shine

Benny Bottema — Sun, 24 May 2009 13:30:53 +0000

[RE: JSF – Still pretty much a steaming pile of donkey turd] – I was replying to Wille Faler’s post about why JSF sucks, when the comment was getting too large, so I made it into a post on my own blog.

JSF is hard to learn yes, but in my opinion it doesn’t suck as bad as Wille says. All the points Wille mentions can be solved by certain libraries or write-once reusable solutions (I’ve included my ‘magical’ combination of frameworks on the bottom). JSF is a diamond in the rough, you just need to make it shine.

The devil is in the details

There are a couple of pitfalls you need to know about with JSF. It’s all really a matter of having read a good book about JSF that points them out, or having learned them the hard way. Luckily I’ve had some guidance by experienced colleagues of mine; I’m guessing that’s the missing factor in Wille’s situation.

Referring to the pitfalls you need to know about, I’m talking about the common beginner’s problems like using JSTL c:tags that cause havoc when combined with those of jsf and facelets. I’m talking about the Ajax4Jsf details as Wille mentioned: once you know what to use it’s easy. Those 48 attributes? most of them are inherited and never used and you can forget about them, and that’s the learning curve. Once you know the right ones, it’s using exactly those, over and over again. And things like how you can incorporate Spring security and stuff like that. Another pitfall that comes to mind is how action=”" work quirky with navigation rules when using the array notation (action=”controller['action']“). And ofcourse there’s the issue of parameterized JSF validators, which needs some understanding. All pitfalls that can baffle a beginner or intermediate.

The thing with JSF is there are a number of little things that are hard to solve, but once you’re past that it does make you much more productive. You just have to have a solid base to start from each project. The pitfalls learning curve is definitely a downside of JSF, but JSF 2.0 is in the making to solve all these issues.

Bad performance or beginner’s mistake?

Then there is this performance issue Wille mentions, where I think he missed the target: JSF does not have to be slow at all. It really depends on how you treat your backing beans. JSF has the weird tendency to call setters/getters multiple times, which seems utterly pointless (it’s related to resolving valuebindings in nested components). I’ve made the mistake before to directly retrieve values from a controller/service in my views instead of a static model (backing bean): this is what makes things slow. JSF in itself isn’t that slow for a webapp: yes there are many redundant calls but we’re not dealing with a realtime simulation application, webapps do just fine. On a sidenote, it also depends on the implementation… JSF is a reference specification, while there are various implementations of the framework (IBM’s, Sun’s etc.)

SEO friendly JSF?

Ahh, but for the JSF Search Engine Friendliness. That’s solved too, somewhat. There’s is a framework called PrettyFaces which allows you to dynamically generate/interpret pretty GET urls with bean values. It’s a great framework that solves a common problem, but there still exists the problem that existing jsf/facelets/richfaces components are not generating SEO HTML code. That’s really the fault of the component makers, not JSF, though JSF definitely isn’t innocent with its POST obsession: PrettyFaces fixes at least that.

Common sense: use frameworks to avoid most pitfalls

Once you’ve got those kind of things down and use a good framework combo, JSF is straightforward. You won’t really need to know about the various phases and you can be very productive if you’ve set up the jsf/facelets components right. I’ve worked with JSF intensively for about a year now in various projects with various implementations and I hardly ever need to use phaselisteners and that sort of stuff. The rare cases where you do need them, you can define these things ones and reuse them in other projects. With this approach I’ve created a template project with some standard libraries, phaselisteners, security set up, facelets components etc. and I’m up and running in no time.

I haven’t sanitized or otherwise cleaned up the template project so I won’t put that up for the time being, but at least I can tell you what frameworks are in it by default.

JSF (MVC)
Facelets (Templating, use of XHTML)
Richfaces (component suite)
Richfaces A4J (Ajax support)
Tomahawk (only for file uploads with the Extensions Filter)
PrettyFaces (for indexable GET urls)

Now that I’ve mentioned these, you should check out JBoss Seam as well, which basically is supposed to do everything the above libraries do combined, plus a couple of things more like solving the conversational scope issue. I haven’t worked with this framework myself though so I can’t speak from experience.

Final note

Although I agree JSF has some annoying pitfalls, shortcomings and a high learning curve, it’s been out there for enough time to pass for supplement frameworks to pop up from under the ground to solve most of these problems.

With the right combination, most classic counter arguments have become obsolete. Maybe it’s time for critics to take JSF as is: incomplete but ultimately making you more productive if combined with the right frameworks.

trackback

Bookmarkable and SEO Friendly JSF with PrettyFaces

Benny Bottema — Fri, 20 Mar 2009 08:00:29 +0000

Yes, it is possible. Yes, it requires hacking JSF with filters and/or phaselisteners and/or custom servlets for encoding/decoding serializing/deserializing GET parameters and force redirects upon JSF view resolvers. The good news however: it’s all been done before and you can just hang back and use a small framework that does all this stuff for you. Enter PrettyFaces.

But before we come to that, I would like to show you how PrettyFaces sums up what you need. This involves solving two problems: The JSF POST compulsion and the JSF Redirect problem. You can in fact solve all of these problems seperately, but PrettyFaces just encapsulates all these annoying things for you in a convenient little jar.

1. GET urls? The POST-back problem with JSF

In one sentence: JSF uses POST requests for *everything*, so there is are no nice copy-pastable GET urls. For example, if you use your generic h:commandLink, a POST submit is being done on the surrounding form to get everything into JSF. JSF needs this because the form contains a lot of extra (meta) data for the input to be processed by the JSF framework. You could for example indicate that the state information should be stored on the view instead of the server, which is then simply added to the HTML form behind the scene. Now this kind of stuff, you don’t want in GET urls. It would cause every action you perform on the website to result in a hideous string of code in the browser bar, which isn’t even copy/pastable to begin with since it contains encoded directions for the server based on specific state (ie. getEmailadresFromCurrentClient, which won’t work if there is no current client available).

There are instances where you would want GET urls, which work in a stateless fasion. For example .../faces/newsarticle?article=2334. However, the developers at JSF appearantly thought “If we don’t need it, you don’t need it”, since there is no way in JSF to configure URL mapping using GET parameters. And this is the heart of the problem. This is where all the hacks come in.

The POST-back solution

There are a couple of methods to approach this problem. Or rather, the concept is the same, but applied in different ways. The concept is that you intercept a HTTP request, manually extract the parameters from the request URL and apply them to your model (a JSF managed bean for example). The POST problem can be split up into two subproblems: GET url interpretation and GET url generation.

Solving the GET url interpretation

You can interpet GET urls in JSF by defining a custom Servlet and have these urls go through it rather than through the faces servlet. In the custom servlet, process the parameters and then redirect the browser to a faces url without these parameters. You need a redirect, since a server-forward won’t trigger another servlet to act on the mapping. If you still want to forward on the server, you need to create a FacesContext, fix the viewroot and handle the view navigation yourself and so imitate what the faces servlet would’ve done. There are libraries out there that contain this solution ready to go.

You cannot do it with a filter for the Faces Servlet, because GET parameters will have been removed already. An alternative to GET parameters is to work the parameters into the url itself (something like http://www.peanutbutter.com/faces/newsitems/params/id-22234.xhtml), but this won’t work either since a filter has no influence on the url passed on to the servlet for further processing. So you can’t remove the url-based-parameters from the URL and let JSF deal with the rest; it will simply fail to understand our custom parameter format.

Another way that does work is to create a custom JSF PhaseListener. You’ll still have lost the GET parameters, but at least you can do something about the url based parameters mentioned in the paragraph before (that and you already have a FacesContext you can use). In this case, you extract the parameters before the RESTORE_VIEW phase and use the resting url to manually set the view root for JSF to work with. Jason put an example of this manual url based parameter PhaseListener mechanism on his blog. Before PrettyFaces I based my own solution on this concept like Jason’s, but Jason incorrectly comments [in his code] that you cannot infer the original view url in this case. I solved this by adding a keyword /params/ in between the url and parameters. Lucas from Amis has a variation on the manual url based parameter PhaseListener mechanism which interprets the parameters and then directly renders the views.

My own manual url based parameter PhaseListener maps the parameters to bean properties in an automated fashion (although the bean names, parameters and properties are hardcoded in a static list at the top, which could’ve come from an xml file or something making this version completely generic -which incidently is exactly what PrettyFaces does-).

Solving the GET url generation

You can’t have GET urls for every state in the application, that would require massive GET urls filled with everything JSF needs to restore its state. What you need are specific cases where you want your users to be able to use a GET url, such as viewing a specific news item, company information, always things based on some identification. For these kind of GET urls, you can write a custom ViewHandler in JSF, which intercepts the view resolution and manually appends the GET parameters. For this to work, you first need to solve JSF’s Redirect problem, discussed in the next section (The Redirect problem with JSF).

Before I turned to PrettyFaces, I wrote my own ViewHandler (for Facelets), which also worked with value bindings in the view mappings in the faces config file. Dominik wrote a nice article on dynamic JSF navigation, which I adapted for this approach. In the faces-config.xml I defined the target urls with the parameters added and the values then being value bindings. A navigation case would look something like the following:

    
    	/pages/newsitems.xhtml
    	
    		#{newsitemController.doSelectNewsitem}
    		ok
    		/pages/newsitems.xhtml?newsitem=${newsitemController.currentNewsitem.id}

The viewhandler I wrote then detected the question mark ‘?’ in there and resolved all parameter values. I made sure the GET parameters were worked into the resulting url itself, which my PhaseListener from the previous section would be able to decipher. The result would look something like ‘/pages/newsitems/newsitem/4.xhtml’. This format then wouldn’t be lost when going through the servlet and its filters and the PhaseListener solution presented in the previous section would understand this format, extract the parameters and fix the url for further processing by JSF, as it originally would have.

Custom GET url generating Facelets ViewHandler with embedded parameters

2. The Redirect problem with JSF

By default JSF runs one URL behind in the browser’s adresbar. Everytime you perform an action the JSF browser gets the URL from the previous view. This is because how JSF works with form submits:

You click on a button which navigates to a different page
JSF submits a request to itself, the same page you were on
JSF handles the various phases and ultimately resolves to a view id, a new page URL
Since JSF submitted to the same page, for the browser it will return to the same URL, while JSF renders the HTML for the next URL. This is where JSF starts to run 1 URL behind
The new form in the page will submit to the for JSF-current URL, which is 1 URL ahead for the browser adresbar
When you now click on a button, JSF submits to the JSF-current URL, at which time the browser finally catches up. JSF however simply jumps ahead again and the whole thing repeats indefinately

The Redirect solution

To get the browser to always reflect the current JSF-viewid-resolved-URL, the servlet needs to make the browser redirect to it. If you don’t, JSF will simply continue under the same URL the browser is in until the HTML form within the page submits to the next URL.

JSF actually contains something useful for this particular problem: redirects. You can add a entry in your navigation case to make the browser redirect to the resolved view URL. This pattern is known as the POST-REDIRECT-GET pattern. The small problem with this pattern however is that you’ll need to add it to each and every navigation case. The big problem is that you lose your request-scoped data between the POST submit and the GET browser redirect.

The solution to both is to register a JSF PhaseListener which intercepts any response-render action, invokes a browser GET redirect instead, but saves any state information to the session so it will still be there when the browsers gets back with the GET request on the new URL. One such implementation is the PRG Phase Listener (Here is another PRG implementation by BalusC). As you can read in the comments though, there still is a shortcoming: it currently only stores the JSF messages data. Adding other data will require an arbitrary selection process since it is unclear what data will be in there to begin with (JSF internal state information stuff) and even less so what data should or shouldn’t be overwritten in the session. This selection process can be cumbersome; for example, what data will you need for a richfaces datatable to still work? Will that still work when it’s updated? I think you get the idea.

How PrettyFaces solves everything at once

So what PrettyFaces does is basically the culmination of the solutions I demonstrated (the GET url generation with dynamic navigation part), but polished as opposed to my own rough proof of concept. Indeed with an extra xml file making the approach generic and with a couple of other nifty features added. Telling you in one sentence what PrettyFaces does is like giving a summary of this entire post:

PrettyFaces: A framework for dealing with GET url in the POST based framework JSF. By returning a viewid like “pretty:home”, PrettyFaces will come into action and look up how the url should be formed using the ‘pretty config’ xml file. It will solve any valuebindings and generate a GET url with a pattern it understand and when entering the url back into the browser, it will return the bean values from the url (sort of reverse valuebinding). So all the problems and their solutions we just discussed are solved by this small library (16k jar as of PF-1.0.0). It will redirect properly and only for the kind of queries we need GET urls for we define a pretty navigation case and return a ‘pretty:viewid’ string to get PrettyFaces to use it.

In addition it offers some tags that, given a pretty maping-id, will generate the GET url for your hyperlinks. Furthermore, since version 1.2 pretty faces contains a mechanism to parse GET parameters using the traditional ?p1=v1&p2=v2 format.

For completeness, here’s an overview of PrettyFaces’ key classes:

PrettyContext: Loads your PrettyFaces context file and contains its settings and mappings.
PrettyFilter: Monitors incoming requests and checks if a requested URL as mapped in the PRettyFaces context. If so, it will request the context, resolve any parameter bindings (inject values into the beans), store any FacesMessage and forward the request to the configured viewid.
PrettyNavigationHandler: Handles navigation after JSF has processed a request. If a pretty-viewid was returned by the JSF action, the PrettyNavigationHandler will pick up on this, find the associated mapping from the pretty context, generate a GET url and redirect to it. In effect it determines which view to render and what appears in the brows addressbar.
PrettyViewHandler: Generates the requested action url from a request url and removes any trailing PrettyFaces directives from the url.
PrettyConfig: Holds the mapping and is returned inside a PrettyContext instance.
PrettyPhaseListener: Restores any FaceMessages stored between redirects, executes any actions defined in the mapping configuration for specific phases. This is after the beans have been injected with values from the GET url as per pretty-mapping. Finally leaves the request handling up to the PrettyNavigationHandler.

trackback

Parameterized JSF Facelets Validators

Benny Bottema — Sat, 26 Jul 2008 15:41:10 +0000

You’d be surprised how hard it is to find good information about how you’re supposed to setup validators that you can parameterize with attributes in your tags; most about validators is very basic and very JSF-only. Or you won’t be surprised at all, because you searched until loss of sanity like me and found this blog. Whatever, here you can read what I found out.

So at first I made the error in not realizing validators under Facelets should be defined in their own facelets tag library. I hadn’t really worked myself into the the theory behind Facelets; I just picked it up as I went… as I do with most things, but there you have it. Turns out Facelets actually makes things very easy concerning validators, were it not for one sneaky little detail:

“parameterizable validators are stateful validators”

We’ll come back to it, but validators generally lose state after the page has been built by Facelets and you have to manually restore that state (including the previously set parameters), by implementing the StateHolder interface.

Oracle has a good article on StateHolder Validators, though I only found it after I learned what to look for.

I resorted to a rather crude catch’em all solution, that tucks away the boilerplate code involved.

Creating a parameterizable validator

Having validators with configurable properties involves the following basic steps:

1. create a JSF validator with the properties you wish to set in your tags
2. register the validator with your faces-config as you normally would in JSF
3. create a Facelets taglibrary file and register it with your application
4. add an entry to this tablib file that defines a validator and points to the faces-config one
5. that’s it, no properties need to be explicitly defined, Facelets will take care of that

We’ll add one more step to it to make the validators actually work:

1.5. modify the validator with a StateHolder solution

1. Create a JSF Validator

So for this example I’m going to take a simplified version of the age validator I made earlier in Streamline your JSF validation framework.

AgeValidator.java

So this validator already has some properties for min and max age we can use. In the previously post article they didn’t work properly though, we’ll fix that today.

2. Register the validator with JSF in faces-config

So before we can use the validator in Facelets, JSF needs to recognize it. Here’s the piece of xml that does that in faces-config.xml:


	quintor.validator.AgeValidator
	nl.quintor.commons.validator.AgeValidator

So you may have noticed I didn’t really use a normal validator id. That’s because I don’t want to confuse them with normal validators for use in JSF only and to illustrate their significance in wiring them to Facelets. Instead I’m using a sort of grouping id by using a shortened version of their full package (for converters it would be quintor.converter.SomeConverter).

3. Create a Facelets tag library file and register it with the application

To be able to use the validators in Facelets, and thereby making use of Facelets parameterizing capabilities, we need to use yet another xml file that Facelets needs.

Create a file in the META-INF webapp folder; I’ll call mine ‘quintor-validators.taglib.xml’. I picked that up from another project that used this convention. Next the taglib file needs to be registered with the web.xml:


 	facelets.LIBRARIES
	
		/WEB-INF/quintor-validators.taglib.xml

4. Add entry that uses the faces-config validator

Here’s the validator definition inside quintor-validators.taglib.xml:




	http://www.quintor.nl/jsf/validator
	
		validateAge
		
			quintor.validator.AgeValidator

1.5. Finally let’s focus on the ‘state problem’

Currently, the age validator is ready to go, if it weren’t for the fact it forgets any value set in the tag. For instance, take the following tag example:

Here the minimum age of 18 is set for validation. If we were to debug the validator, we’d notice the setter is being called when the page is being build up. If we then submit the form, the validator is recreated, but the setter is not being called again thus the validator reverts to its default values!

How then, can we keep the values set by the attributes? The answer lies in the StateHolder interface that comes with JSF, or rather why you need StateHolder. The problem lies in the fact that JSF keeps everything page scoped by default and stores all components in the Response object (which would explain why the setter is being called during page-build). Through the use of the StateHolder interface, JSF is able to carry a component’s state across requests and responses.

An alternative to StateHolder would be to make the validator serializable, as the MyFaces wiki reveals on JSF State Management, but that’s a rather implicit solution. I’d prefer the explicit version by implementing StateHolder. Instead of having each and every validator implement StateHolder, I chose for a more ‘catch all’ solution. This solution involves an abstract base class that stores the complete state of a given component (validator or converter) and restores this.

Here’s the class and GenericUtils which harbors some boilerplate code:

AbstractStateholder.java
GenericUtils.java

So what happens is that we just ignore transient and let JSF deal with that. But when saving/restoring state we just crudely take Apache’s BeanUtils and create a clone of the current validator instance and take over all of its properties, which will now need getter methods as well. The copied state is limited by what properties on the validator has getters/setters defined for them. When JSF is asking the validator to restore its previously stored state, we just slam the cloned validator’s properties on the current one.

Here’s the modified AgeValidator now: AgeValidator.java modified

The new version only has some getter methods added so that the abstract stateholder class can retrieve the values for state-saving. Now, the validators are being parameterized by Facelets (common conversions done automagically) and the attributes on the tags are being remembered on the validator to the point of actual validation.

Nice, huh.

trackback

Streamline your JSF validation framework

Benny Bottema — Sun, 13 Jul 2008 17:40:43 +0000

I was working a JSF project which, as all JSF projects do, needed a bunch of validators. It was getting a little bit messy having a lot of boilerplate code and validation algorithms that couldn’t be reused. So I decided to streamline the code and usage of validators in JSF in general, in combination with dealing with validation messages optionally using resource bundles.

The solution I’m suggesting isn’t rocket science, but it serves its purpose in keeping everything maintainable, understandable and easy to work with.

Let me know what you think.

[ Download all sources ]

The general idea

So here’s the general layout of what I had in mind:

Group all validation logic in methods in an independent utility class
Have an abstract validation class, which takes care of some logging and validation errors.
Add subclasses of this abstract validation class that merely invokes the validation logic on a separate utility class

The methods should be kept in a separate utility class, so that these validations can be used anywhere in the application and furthermore: outside JSF applications. Also, since all validations are now organized in one central location, we can deal with validation messages uniformly across all validation methods, within the utility class. We’ll see about that later.

Setting up the Validation utility class

What I’m going to do is define constants with error codes, that should be able to be mapped directly to message id’s in message resourcebundles. Realizing not all projects nescesarily use these bundles, we’re going to create default messages as well. These default messages are there to be used by the various validators, but don’t have to be used at all.

public static final String VALIDATIONERROR_BIRTHDATE_TOOYOUNG = "validationerror.birthdate.tooyoung";
static final Map defaultMessages;
static {
	// set default error messages
	defaultMessages = new HashMap();
	defaultMessages.put(VALIDATIONERROR_BIRTHDATE_TOOYOUNG, "Minimum %s years of age allowed");
}

I split up the validator utils into two classes. A ValidatorMessages class which contains all the constants with the error codes and default messages. And then ofcourse ValidatorUtils, which contains all validation algorithms, because I wanted to avoid having a validation God Class. I’ve thought of making the ValidatorMessages an interface, but I couldn’t semantically justify that.

ValidatorMessages.java
ValidatorUtils.java

These classes use some utility functions from GenericUtils (such as the regexp helper method).

GenericUtils.java

Setting up the abstract validator class

The abstract validator class is really the engine behind the new validation framework. It should do some logging, some more logging in case of invalidation, getting the correct message from either the list of default messages or the message resourcebundle (if available) and then it should throw a JSF validation exception.

AbstractValidator.java

The abstract validator uses a method from yet another utility class, specific to JSF applications: JSFUtils. What it does is try to return a message from the default application resource bundle, and if unavailable (either the bundle or the specific message) it will return the given backup message.

JSFUtils.java

So the first thing you’ll notice is that the abstract validator needs to be instantiated with a default field name. This is so that if you omit the corresponding attribute in the validator tag in your JSF page, there will be a default name in the error message to the end-user.

Furthermore, the abstract validator uses a utility method to get a message from the default application resource bundle, but returns a backup message if the resource bundle or message within is unavailable. Since the way the resource bundle is being fetched depends on a FacesContext, the utility is called JSFUtils and is specific to JSF applications, just as the JSF Validator shells are.

Setting up the validators

The actual validators being registered with JSF are now very easy to set up. In fact, they now function merely as glue between the AbstractValidator and the ValidatorUtils, while providing entry points for the JSF validation framework.

Here are two example validator classes:

PostalcodeValidator.java
AgeValidator.java

As you can see the subclasses are extremely lightweight and only contain some boilerplate code to optionally customize the error messages specific to that validator class and even then the error messages themselves are kept in message bundles or ValidatorMessages and handled by the AbstractValidator class.

To configure JSF with the concrete validators:



	...

	
		validatePostalcode
		nl.quintor.commons.validator.PostalcodeValidator
		
			fieldName
			java.lang.String
		
	
	
		validateAge
		nl.quintor.commons.validator.AgeValidator
		
			fieldName
			java.lang.String
		
		
			min
			java.lang.Integer
		
		
			max
			java.lang.Integer

And to actually use the validator in some page:

Roundup

In retrospect, here’s a short impression of the packages now in use:

Let’s summarize how the logic is spread out among the classes:

GenericUtils: contains some generic functionality neutral to all applications, such as regexp methods
JSFUtils: contains generic functionality specific to JSF applications, such as getting messages from a FacesContext resourcebundle
ValidatorUtils: contains the validation methods, neutral to all applications, such as validateAge
ValidatorMessages: encapsulates the error codes and their default messages that can be returned by validation methods in ValidatorUtils
AbstractValidator: contains logic used for all validators, such as logging, determining validation message, throwing JSF validation exceptions
ConcreteValidator.java: contains the default field name for end-user feedback purposes and calls the correct validation method in ValidatorUtils and returns its result to the AbstractValidator validation method (and optionally customizes the message)
faces-config.xml: contains registration for concrete validators including properties that can be set (ie. limits for the age validator)
some-page.jsp/xhtml: contains the input fields and nested validator tags, optionally with attributes to customize it

So to actually add a new validator, you can follow the next steps:

Add the validation codes and default messages you’ll need to ValidatorMessages
Add a method to the ValidatorUtils that performs the validation and returns one of these messages
Create a subclass of AbstractValidator, call the super constructor with a default fieldname and implement the validation method, calling the corresponding validation method in ValidatorUtils
Register the validator with your faces config file

Benefits of this approach

The benefit is ofcourse that everything is being managed separately and can be reused; you can reuse the validation method anywhere across your projects and what’s more: you can use the same validation methods in non-JSF applications. Also with this approach you can easily junit test the validation methods. When adding new validators, you add very little code but highly concise and cohesive code.

In this approach the Validator class acts as a shell around the actual validation logic and can therefor be very lightweight. Now you can add validators with the least amount of code possible while maintaining maximum flexibility.

Conclusion

So, coming to the conclusion, I hope you can use this stuff. I know it works beautiful for me, but If you have suggestions, as I have no doubt someone can do this all even better, let me know!

Slashdot It! / trackback