These Aren’t Your Mother’s Web Frameworks

I’ve been using JSF for the last coupl’a months. It’s not a perfect web framework, but there’s a lot of industry adoption, so we’re trying it out. Mostly we’ve been able to build our application quickly and JSF has had lots of good stuff to make use of. Standard components that we expect of modern web frameworks: table components, buttons that bind to methods, etc.

Some times I miss certain features of Tapestry. I’ve already written about configuration in JSF, and how I really wish there wasn’t so much Struts-like XML. But every once in a while I encounter a JSF concept that seems so similar to a Tapestry that I get confused by their differences.

One such concept is the concept of “Phase Listeners”: according to the JSF API docs, the PhaseListener is:

An interface implemented by objects that wish to be notified at the beginning and ending of processing for each standard phase of the request processing lifecycle.

Knowing Tapestry, I’m immediately reminded of listeners like the PageValidateListener. The PageValidateListenerfills a common need: your page class is created and input data has been copied to it, but you need to know when all the input data has been filled, and you want to start consulting services to get data that needs to be displayed.

Reading the documentation, it seems like the PhaseListeneris pretty much the same thing. There’s an explicit definition of JSF phases:

But there’s a difference. Phase listeners are generally expected to be registered at application start-up time. The interface isn’t intended to be applied to something with request-level scope, like a “page” bean (a “backing bean” in JSF-speak). In JSF, there isn’t something quite like the Tapestry listener interfaces. But there is the opportunity for confusion.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply