Design with the JSF architecture

Discussions

News: Design with the JSF architecture

  1. Design with the JSF architecture (17 messages)

    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.

    Threaded Messages (17)

  2. Design with the JSF architecture[ Go to top ]

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

    Sorry, bit of a contrarian personality.
  3. Usage of too many patterns[ Go to top ]

    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.
  4. Usage of too many patterns[ Go to top ]

    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>
  5. Usage of too many patterns[ Go to top ]

    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 :-)
  6. Pattern as brain food[ Go to top ]

    As the late John Vlissides wrote in his 1999 Book Pattern Hatching: patterns are primarily food for the brain, not fodder for a tool.
  7. Design with the JSF architecture[ Go to top ]

    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.
  8. 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 :)
  9. Ok no more coffee for you :)

    ButifIdontgetmycoffeeIgetitchygrumpygargplsfftack!
  10. Design with the JSF architecture[ Go to top ]

    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
  11. Design with the JSF architecture[ Go to top ]

    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.
  12. Design with the JSF architecture[ Go to top ]

    I remember about a year and a half ago, people were talking about pattern sickness in the J2EE industry ...
  13. Design with the JSF architecture[ Go to top ]

    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?
  14. Design with the JSF architecture[ Go to top ]

    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.
  15. Design with the JSF architecture[ Go to top ]

    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
  16. Design with the JSF architecture[ Go to top ]

    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 ...
  17. Design with the JSF architecture[ Go to top ]

    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.
  18. Design with the JSF architecture[ Go to top ]

    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.