Continuing our look at JSF (see previous blog here), one of the biggest complaints about JSF is the Lifecycle. And it's not hard to understand why - here you are, just about to write a Hello World application, and the folks who wrote the documentation hit you with something that looks like this:

Wow. Looks complicated. But really, for many tasks, you don't need to know most of this, and that's more true with JSF 2 than ever. (I'll go over a cheat sheet of what you really need to know later.)

The main reason you as a developer would need to understand the Lifecycle is to develop your own components. And that's one place where JSF really used to fall short - for years, there were a very limited number of components, forcing you as often as not to write your own. And once you did, you were neck deep in lifecycle issues, making component writing difficult.

So, some good news:

There's lots of JSF components already available

There's several places you can go to get lists of components, but I like JSF Central's list. And unlike a lot of my other points about JSF, these component libraries are available today, usable in production immediately, without having to wait for the next release.

Lots of JSF component libraries support Ajax functionality

There's also lots of component libraries which already support Ajax today, and that support works just fine in JSF 2. The three most popular are probably Apache Trinidad, JBoss RichFaces, and ICEfaces. All of these frameworks are also diligently working on moving to JSF 2, as my colleague Roger Kitain recently blogged.

Writing components is now much, much easier

In fact, dare I say it? It's now easy. At least, for most common cases. JSF 2 has the idea of composite components, which is a templating approach to component creation. I outlined the basics in a blog some time ago, it's pretty simple, and doesn't require any knowledge of the lifecycle to implement - or even any knowledge of the underlying Java classes, for that matter. Just patch together a few existing components into an xhtml page - no more writing JSP tag handlers either.

As a quick example, here's how you could create a text field component that always has a yellow background:

<composite:interface>
    <composite:attribute name="value" required="false"/>
</composite:interface>

<composite:implementation>
    <h:outputText value="#{compositeComponent.attrs.value}"
        style="background-color: yellow"/>
</composite:implementation>

And using it is as simple as saying <ez:out value="Test Value"/> . It really doesn't get a lot easier than that.

What you need to know about the JSF lifecycle

So, if you don't need to know that complex lifecycle, what is it you do need to know? You need to know that when JSF first receives a page, it validates it - that can be either because you put a validator on a field, or because you said the field was required. Then, if all validations pass, it applies the new values into your backing beans. If validations fail, you don't get those values applied - the old page is sent back to the client, with an error message. Once those values are applied to the beans, any value change events you coded are set off, after which the whole response page is sent back to the client. Put this way, is the JSF lifecycle really so daunting? In practice, the only time I see folks get hung up is on the part where if validations fail, the values aren't set.

More in the next installment.