Articles


Exonerating the JSF Lifecycle

One of the many accusations aimed at JSF is the definition and complexity of the JSF Lifecycle. The JSF lifecycle is responsible for processing the page creation and submission and orchestrates the different pieces of the framework. A more thorough description of the process can be found in this article by Rick Hightower. At a high level, this process is defined as :

  1. Restore View – JSF builds the view for the first time or restores the component tree.
  2. Apply Request Values – take the values from the submitted form, convert them and put them in the component objects.
  3. Process Validation – validates the converted values based on applicable validators. If validation fails, we jump to the last step.
  4. Update Model Values – take the converted and validated values and put them in the properties of the backing bean.
  5. Invoke Application – Once your backing beans have been updated, the application is called and usually code is executed against the backing beans.
  6. Render Response – the response is generated and sent back to the users browser.

It is claimed that it is an unnecessary complexity that the developers must deal with in order to use JSF. Understanding the lifecycle is not a requirement but will help you understand what is going on, but what is objectionable about this assertion is that this lifecycle is no different than just about any other web framework. One Spring MVC user has posted a cheat sheet which is quite a handy guide to the form controller. It shows how complex Spring MVC can be in executing identical behavior. Wicket and even ASP.net perform the same steps in that it utilizes a server side model, pushes the values in, converts and validates them, handles events, and then renders a response. Even the most simplistic frameworks must always extract values, convert and validate them since when working in the web, you are merely pushing strings between server and client. At some point these string values be converted to meaningful data and objects and the consequences of invalid content must be dealt with. JSF is quite upfront about this process and even lets you hook in to the lifecycle events through the JSF PhaseListener.

Growing up a programmer in the 80s

Despite the fact that there are plenty of free languages and development tools available online, there is still a much larger barrier to entry for someone who wants to get started as a programmer compared to nearly 30 years ago. I have fond memories of the computing of the 80s so I thought I’d take a quick trip down memory lane and write about my personal exerience of becoming a programmer. It may also be of interest to those familiar only with the Silicon Valley version of the history of computing since this covers events from the other side of the pond in the UK. When historians talk about the history of computing, they really only cover things like the TRS80, Altair and rise of the PC and Mac, yet there were many important and competitive developments in Europe that are often not included as part of this history.

Read More »

Get yourself a reputation at work

For most of us, as programmers, we are a pretty lucky bunch. We get paid handsomely (or at least nicely) for doing something which we enjoy, will never go out of fashion and provides a great deal of benefit to the companies we do it for, if not the world at large. While we may not be working in the IT fields we want to be working in or for the companies we want to be working for, we still get to enjoy the process of writing code on a daily basis for a living.
Read More »

Announcing CDISource

In the last few weeks I have been rather busy working on a new project with Rick Hightower, who is fairly well known for his training and writings on Spring and JSF, and Rob WIlliams who is a blogger known as much for meddling in new technologies (and getting mad at them) as he is for intertwining various historical and literary references in his posts. The result of this is the CDISource project which aims to advocate and facilitate the use of the JSR 299 – Java Contexts and Dependency Injection framework across the Java landscape.

If you’ve seen my posts or my site before, you’ll no doubt be aware that I have written at great length about Java EE 6, JSF, CDI , EJB and so on. What I haven’t written about is the many frustrations I’ve come up against in dealing with these frameworks on their own and especially when combined, or how their usefulness is often constrained to the application server container.

Java EE in some ways is an archipelago of frameworks that lacks the cohesiveness and all in one wide screen vision that software developers need. Java EE is about the enterprise, in reality its about the web, or even more specifically about Java EE containers. There’s a whole slew of uses for a good type safe and flexible dependency injection and AOP framework and such as CDI outside of Java EE containers but there is very little information and code to make it actually work.

Our goal is to make CDI useful and usable on its own without Java EE 6, and to give developers the tools and information to do so. To let them write vendor neutral and portable code, and apply agile and best practices. Developers know how to write good software and don’t want to sacrifice that for the sake of using a framework to make things easier. To that end we aim to provide code and information that will help facilitate those practices.

There will be some learning for ourselves along the way and we will have to change some of our previously held concepts. I know over the last few weeks having been getting CDI working and useful outside of the web container it has really altered my perspective on how I think about the dependencies and structure in CDI applications. My perspective has changed even more than when I wrote A Little Less Conversation.

As much as I hate to say it, we did come up with a mission statement, although we found it fairly easy and enjoyable to clearly defined the goals and attitudes of the project.

Our mission is to :

  • Promote and facilitate the use of the Java Context and Dependency Injection (CDI) framework in relation to as many aspects of application development as possible.
  • Enable developers to take advantage of CDI independently of Java EE.
  • Provide lightweight, lean and agile access to the underlying CDI container as a core principle in our efforts.
  • Make testing easy without requiring a complex set of tools or complex deployment scenarios.
  • Enhance both Java EE development as well as the use of CDI in non Java EE application where possible.
  • Promote and enable the use of CDI in a vendor neutral environment and maximize the portability of application code across CDI implementations.
  • Not reject the ideas of Java EE but expand the usability of CDI outside the borders of Java EE application servers with frameworks that are not a part of the specification.
  • Not reject other CDI efforts but to provide another venue to promote those efforts. This is an addition. This is another voice in support of CDI.

We are pretty excited that so far we have been able to live up to the intent of our mission statement with everything we’ve done so far. Over the next few days and weeks you will see articles and tutorials come out of Rick, Rob and I as we write about the CDISource project and we start to showcase some of the code we have written and start giving you an idea of where we are heading.

Right now we have vendor neutral support for starting up CDI outside of the web container and also for testing CDI beans with minimal configuration and intrusion on your test cases. We also have a few other pieces that are nearly ready, as well as dozens of ideas to get started on.

You can start by looking at Ricks brand new introduction of CDI over on JavaLobby.