Design patterns help users to abstract details at a higher level and better understand architecture. If you are familiar with Gang of Four design patterns and the JavaServer Faces (JSF)framework in general, this article will help you gain insight about the design patterns used in JSF framework, and how they work in-depth.

The JSF framework leverages Singleton, Model-View-Controller, Factory Method, State, Composite, Decorator, Strategy, Template Method, and Observer design patterns. It's a robust framework in that its architecture is based on already proven design patterns, which are utilized very nicely in the JSF framework.

An example of the article's content, from the section on the State Pattern's usage in JSF:

The intent of the State pattern is to distribute state-specific logic across different classes that represent states. FacesServlet invokes execute and render methods on a LifeCycle instance. LifeCycle collaborates with different Phases in order to execute a JSF request. JSF implementation follows the State pattern here. If this pattern wasn't used, LifeCycle implementation would be cluttered with a lot of conditionals (or "if" statements). JSF implementation creates separate classes of each state (or phase) and invokes steps. A phase is an abstract class that defines the common interface for every step. In the JSF framework, six phases, or steps, are defined: RestoreViewPhase, ApplyRequestValues, ProcessValidationsPhase, UpdateModelValuesPhase, InvokeApplicationPhase, and RenderResponsePhase.

As in the State pattern, LifeCycle passes a FacesContext object to the phases. Each phase or state changes the contextual information passed to it and then sets the flag in the FacesContext itself to indicate the next possible step. JSF implementation alters its behavior with each step. Each phase can be responsible for the next phase. FacesContext has two flags -- renderResponse and responseComplete -- to change the sequence of execution. After execution of each step, LifeCycle checks whether either of these flags was set by the previous phase. If a responseComplete is set, LifeCycle abandons the execution of the request altogether. If a renderResponse flag is set after some phase, JSF implementation skips remaining phases and goes directly to the render response phase. If neither flag is set, LifeCycle executes the next step in the sequence.

I love JSF. It's a very good framework.

Sorry, bit of a contrarian personality.

Can be dangerous as well, but not using patterns is worse.
The thing is you have to apply patterns where it makes sense
and makes the code more maintainable.

The BO/DAO pattern for instance is a very good approach, but going the pattern route down to smallest problems which are probably more maintainable by straight forward approaches, is overkill and you end up in a maintainence nightmare with hundreds of classes with a few locs, where a handful of classes would have been more reasonable to have a maintainable system.

Been on that side of the fence as well, and I am currently rowing back to a certain degree, to keep a set of core patterns for problem domains but trying to find a good middle ground to reach ultimate maintainability.

Distinguished computer scientist C. H. R. Hoare eloquently described this danger in his 1980 (yes, 1980!) Turing Award Lecture, speaking of the design of the PL/1 programming language:

<quote>
At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way -- and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.
</quote>

Distinguished computer scientist C. H. R. Hoare eloquently described this danger in his 1980 (yes, 1980!) Turing Award Lecture, speaking of the design of the PL/1 programming language:<quote>At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way -- and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.</quote>

Yep, that's a great quote, but I'm still awaiting to meet an IT manager who knows who this "whore" guy was :-)

As the late John Vlissides wrote in his 1999 Book Pattern Hatching: patterns are primarily food for the brain, not fodder for a tool.

The JSF framework leverages Singleton, Model-View-Controller, Factory Method, State, Composite, Decorator, Strategy, Template Method, and Observer design patterns.......

Ah! I get it! The more patterns you use, the more likely the project is not a hunk of junk?

I quess the same might be true of buzzwords? JSP/SOA/SOAP/UML/EMF/XML/RoR/JBOSS/M-O-U-S-E ... it must be great!

Hardly.

The JSF framework leverages Singleton, Model-View-Controller, Factory Method, State, Composite, Decorator, Strategy, Template Method, and Observer design patterns.......

Ah! I get it! The more patterns you use, the more likely the project is not a hunk of junk? I quess the same might be true of buzzwords? JSP/SOA/SOAP/UML/EMF/XML/RoR/JBOSS/M-O-U-S-E ... it must be great!Hardly.

Ok no more coffee for you :)

Ok no more coffee for you :)

ButifIdontgetmycoffeeIgetitchygrumpygargplsfftack!

I could be wrong of course, but as per me the whole text (and the quoted part especially) looks like anti-JSF stuff ;-)

Dmitry
http://www.servletsuite.com

I could be wrong of course, but as per me the whole text (and the quoted part especially) looks like anti-JSF stuff ;-)Dmitry

Not at all. This is information about how JSF works, not what developers are expected to have to do to use it. JSF is a very powerful framework because of this structure, which allows all sorts of extensions and alternatives to be plugged in.

I remember about a year and a half ago, people were talking about pattern sickness in the J2EE industry ...

I remember about a year and a half ago, people were talking about pattern sickness in the J2EE industry ...

I assume you have links to such discussions, along with some reasons why this is relevant?

I remember about a year and a half ago, people were talking about pattern sickness in the J2EE industry ...

Maybe so. But. (Not wanting to start a pattern flame here.) The code has to be written somehow, and it still is better to do it according to a well established principle, than to come up with something new every time. Maybe not for the code quality itself, but surely for the documenting aspect of it.

So if someone tells me that a framework use this pattern here and that pattern there, then I'm more easily confident that I will understand the framework, since I understand the patterns.

Pattern usage does not say anything about the framework itself, only something about how easily someone will understand it.

I don't get the intent of this text. It's just a short summary of the most common GOF patterns. You will find them in any software design that has a certain size. So how is that linked to JSF?

My guess is that the buzzword bingo went like this: "Well, we still need some article for our dW Java section..." - "Why not let somebody write something general about design patterns?" - "But there have been thousands of articles on that subject..." - "Wait, I've got an idea: We could write about the design patterns in some random software that's been hyped a lot lately -- let's say... JSF?"

DEFINITELY NOT WORTH READING...

Just my .02$, Lars

I don't get the intent of this text. It's just a short summary of the most common GOF patterns. You will find them in any software design that has a certain size. So how is that linked to JSF? My guess is that the buzzword bingo went like this: "Well, we still need some article for our dW Java section..." - "Why not let somebody write something general about design patterns?" - "But there have been thousands of articles on that subject..." - "Wait, I've got an idea: We could write about the design patterns in some random software that's been hyped a lot lately -- let's say... JSF?"DEFINITELY NOT WORTH READING...Just my .02$, Lars

GOF patterns are cool, It looks like there are no reasons NOT to use JSF ...

I don't get the intent of this text. It's just a short summary of the most common GOF patterns. You will find them in any software design that has a certain size. So how is that linked to JSF? My guess is that the buzzword bingo went like this: "Well, we still need some article for our dW Java section..." - "Why not let somebody write something general about design patterns?" - "But there have been thousands of articles on that subject..." - "Wait, I've got an idea: We could write about the design patterns in some random software that's been hyped a lot lately -- let's say... JSF?"DEFINITELY NOT WORTH READING...Just my .02$, Lars

The best thing about the cynics is that they, I mean "we", are usually right.

So effectively, this article simple stated the Gang of Four Patterns and said here this is what it means in JSF. Ok, so I was suppose to learn something? I knew that JSF was built around these patterns. I think it was good that it was explained as to the goals of using the chosen pattern for a particular part of the JSF design.