Here’s a list implementation I came up with to enable true paged data fetching completely transparent to any
List user. It works independent of persistence layers, such as JPA implementations etc and it can be used by anything that only needs a List, such as a
< rich:dataTable >.
[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.
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 separately, but PrettyFaces just encapsulates all these annoying things for you in a convenient little jar.
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.
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 ]