wood burning stoves 2.0*
The moose likes JSF and the fly likes Front Controller & JSF Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Front Controller & JSF" Watch "Front Controller & JSF" New topic
Author

Front Controller & JSF

Mahesh Subramaniya
Greenhorn

Joined: Dec 12, 2004
Posts: 19

I'm trying to evaluate my design patterns to be used in my architecture. I know Front Controller can be designed to delegate work to respective Helpers. But if I leverage JSF and faces-config.xml, should I still need to worry about the Front Controller pattern, as I understand JSF also does similar work. Correct me if my understanding is wrong.

Thanks.


Mahesh Subramaniya

OCMJEA/SCEA
Guy deLyonesse
Ranch Hand

Joined: Apr 12, 2011
Posts: 200

Not sure I understand what you mean. Can you be a bit more specific?
Mahesh Subramaniya
Greenhorn

Joined: Dec 12, 2004
Posts: 19

Guy deLyonesse wrote:Not sure I understand what you mean. Can you be a bit more specific?


Sorry about the mis-clarity.

To ask the same question in another way, to which JEE5 design pattern I can correlate the JSF framework along with Backing/managed beans and faces-config.xml's Navigation part? Will it be good enough to correlate with FrontController design pattern?
Guy deLyonesse
Ranch Hand

Joined: Apr 12, 2011
Posts: 200

JSF is an MVC design pattern, which I believe is related to the Front Controller.

With the way JSF implements MVC, you can actually have multiple backing beans serving as the Controller, with the xhtml files being the view and some number of data objects serving as the Model. You can also have POJOs providing functionality and support.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

I'd have to go back and RTFM on Front Controller, which is too much like work

JSF is a pretty pure implementation of the MVC paradigm (MVC isn't technically a Pattern, it's a collection of co-operating patterns).

In traditional MVC, you have a master Controller and possibly some child controllers attached to child Views.

In JSF, the master Controller is the FacesServlet, and you almost never customize this. About as close as you will get is the configuration parameters in web.xml. Child controllers are supplied as part of the JSF tag implementations. Again, you don't actually write controller code here, as the out-of-the-box implementations are sufficient. About the only place you write controller code of your own is when you implement JSF event listeners, and clean JSF apps have few, if any of those. You can also consider Validators and Converters to be Controller code, but there's a rich stock set of those as well, so again, user-supplied function are rare here.

The JSF backing bean is technically the model (NOT a controller!!!) in the MVC paradigm. What can confuse people is that backing beans aren't "pure" MVC models. They can house controller code (listeners, etc., but they primarily are model objects. They also house action processors, which have no real MVC counterpart. Action processors act on the model, and in most complex JSF apps, tend to invoke business and/or persistence objects from outside the JSF MVC domain.

In other words, although JSF is built on the basics of successful design patterns, JSF tends to form patterns of its own.


Customer surveys are for companies who didn't pay proper attention to begin with.
leo donahue
Ranch Hand

Joined: Apr 17, 2003
Posts: 327
Patterns depend on what your web app does.

Fascade pattern is a good starting point.


Thanks, leo
Guy deLyonesse
Ranch Hand

Joined: Apr 12, 2011
Posts: 200

Tim Holloway wrote:
The JSF backing bean is technically the model (NOT a controller!!!) in the MVC paradigm.


I stand corrected.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

Guy deLyonesse wrote:
Tim Holloway wrote:
The JSF backing bean is technically the model (NOT a controller!!!) in the MVC paradigm.


I stand corrected.


When it comes to Ideological Purity, JSF backing beans don't do very well. I've seen more than one system where someone actually named their backing beans "controllers".

It can be confusing, since certain controller functions can be defined within Backing beans. Also, some people think that the action methods are Controller methods, but that isn't true. In a more traditional MVC such as Swing, the actions are invoked by the controllers, but are the hand-off points between MVC and business logic. JSF action processors are much the same.

Although a Backing bean could be coded as a logic-only object, in reality it's virtually unheard of. But there is one and only one place in JSF that acts like an MVC model, and that's Backing Beans.
Guy deLyonesse
Ranch Hand

Joined: Apr 12, 2011
Posts: 200

When I was first learning JSF it was likened to the .NET approach, with the backing bean being the direct analog to the .NET codebehind.

What I do with my backing beans these days is to try and keep them exclusively for methods that directly interact with the view page, saving the business logic for separate POJOs. I'm not so good with keeping the code separate with my model beans (using a tree model as a backing bean for a tree view in ICEfaces, or having a model bean to define a list of items for a selectOneMenu control for example) which coincides with what you said about a backing bean technically being a model.
leo donahue
Ranch Hand

Joined: Apr 17, 2003
Posts: 327
Tim Holloway wrote:Although a Backing bean could be coded as a logic-only object, in reality it's virtually unheard of.

Explain "logic-only" object.

Backing Beans bind to the UI - components, converters, listeners and validators.

What name are you giving to beans that do not interact with the UI?
Mahesh Subramaniya
Greenhorn

Joined: Dec 12, 2004
Posts: 19

Good Explanation Tim!

Tim Holloway wrote:
Again, you don't actually write controller code here, as the out-of-the-box implementations are sufficient. About the only place you write controller code of your own is when you implement JSF event listeners, and clean JSF apps have few, if any of those. You can also consider Validators and Converters to be Controller code, but there's a rich stock set of those as well, so again, user-supplied function are rare here.

What I understand, a component as a "Controller" is (in the programming), a component which receives all the info, uses faces-config.xml to derive UI component, execute the appropriate helper code and receive the signal to get the next UI component and dispatch the UI. Which is what Wicket is pretty much trying to do / make people clear.

But in real world, Controller is always looked as a executable component which processes the UI's input and action. But which actually should be called as "Action Listeners" ( from a Swing's perspective lets say).

So, in overall sense when a JSF page uses a POJO means, that is pretty much an Action Listener POJO or a UI component ( say button ) POJO, which does some server processing on receiving an event ( say "login" ). Am I right in this understanding?
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
JSF is "crap" and usually any attempts to explain or teach JSF will be crappy
leo donahue
Ranch Hand

Joined: Apr 17, 2003
Posts: 327
Jimmy Clark wrote:JSF is "crap" and usually any attempts to explain or teach JSF will be crappy

Well, tell it to Ed Burns.

JSF is the JavaEE 6 "standard"... like it or not. We might as well get rid of all frameworks then and let everyone go back to having different standards for doing the same thing.

It's bad enough when most employers make the following corelation... what you haven't driven my car, then you must not know how to drive.

This post is a prime example, there are people who are trying to understand what the "controller" is in JSF and we have varying opinions.

Sorry for the soapbox. I get grumpy when people make generalities without any support. It's ok with me if you think JSF is crap, but I'd like to hear why you think so. Is it the xml configurations? Is it the lifecycle? Is it that you have to "POST" everything? I'm just curious.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Good point Leo. It has been many years since I personally wrote any front-end code, so my please add this context to my earlier statement. However, after close study of the framework, it quickly reminded me of a CS student's nightmarish attempt to comply with the Model-View-Controller design pattern.

In standard MVC, the View is the graphical user interface controls that allow the Human user to use the Model application. And the Controller is the mediator working between the View and the Model application. The strongest benefit of the MVC pattern is to easily create and apply multiple Views to a single Model application.

Wireless View ----------> Business Application A

HTML View -------------> Business Application A

Desktop View -----------> Business Application A

DOS Command Prompt View --------------------> Business Application A

UNIX Command Prompt View -------------------> Business Application A

If you build any portion of the Model in a View or with the technology of the View, it will be difficult to easily create multiple Views without redundancy and/or duplication, or extra effort (time). If JSF allows you to include Model, then it strongly deviates from the MVC pattern. Hence, it is crap and shouldn't use MVC in it's marketing materials.
leo donahue
Ranch Hand

Joined: Apr 17, 2003
Posts: 327
*revised*

JavaServer Faces is:
from Oracle: A set of APIs for representing UI components and managing their state, handling events and input validation, defining page navigation, and supporting internationalization and accessibility.
http://www.oracle.com/technetwork/java/javaee/overview-140548.html

JSF provides a way to separate presentation from model logic.
Please point me to where JSF says, please place your "model" logic in the UI... in the API or in the Spec.

JSF alone isn't responsible for what you have said about allowing "model" to exist in the view. You can make that argument then for JSP or Servlets or the others.

MVC is a architecture that is up to the programmer to implement.

I think the argument that you are making is that the "programmer" of a JSF application deviates from the MVC pattern by using model in the view. I think what you are trying to say is that some programmers are ill-informed about JSF.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Good points Leo. I would only defer from considering the Model-View-Controller object-oriented design pattern as an "architecture." It is simply a pattern to basically help a designer organize how the objects of an application interact with each other.

An application's architecture deals with and includes much more than the design of object interactions or how components are deployed for example. An application's architecture includes: hardware, security firewalls, RSA tokens, database management systems, operating systems, non-object-oriented applications and scripts, EIS, diagrams, blueprints, documentation, and much more.

If an individual thinks of the MVC pattern as an "architecture", then they are minimizing what an architecture really is. And this is not a good thing.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

Mahesh Subramaniya wrote:Good Explanation Tim!

Tim Holloway wrote:
Again, you don't actually write controller code here, as the out-of-the-box implementations are sufficient. About the only place you write controller code of your own is when you implement JSF event listeners, and clean JSF apps have few, if any of those. You can also consider Validators and Converters to be Controller code, but there's a rich stock set of those as well, so again, user-supplied function are rare here.

What I understand, a component as a "Controller" is (in the programming), a component which receives all the info, uses faces-config.xml to derive UI component, execute the appropriate helper code and receive the signal to get the next UI component and dispatch the UI. Which is what Wicket is pretty much trying to do / make people clear.

But in real world, Controller is always looked as a executable component which processes the UI's input and action. But which actually should be called as "Action Listeners" ( from a Swing's perspective lets say).

So, in overall sense when a JSF page uses a POJO means, that is pretty much an Action Listener POJO or a UI component ( say button ) POJO, which does some server processing on receiving an event ( say "login" ). Am I right in this understanding?


You're thinking in terms of specifics, but MVC is an abstraction. In MVC, the controllers are components which link the Model and a View. Note that I said "a" View and not "the" View. That's because in a good MVC implementation you can have multiple views of a model, such as, for example, a spreadsheet view and a pie-chart view, both using the same model at the same time.

The Controllers, therefore are concerned ONLY with the UI aspect. Actual business logic and interaction with filesystems, databases, and so forth is outside their scope. JSF Actions don't directly interact with the View as their primary function - they action on the Model and connect to (or supply) Business Logic, which disqualifies them as Controllers. On the other hand, a ValueChangeListener on a drop-down list might interact with the Model to setup a second-level drop-down list (for example, states within a country). Its primary function, therefore is as a Controller. In fact it's a VERY bad idea to put any sort of business-related logic in a ValueChangeListener. What I typically do in a case like a 2-level list selection is have the listener set a semaphore that indicates to the secondary control's SelectionList "get" accessor that it should go to the database and read (and cache) an updated selection list.

Incidentally, I've seen some confusion about the term "Business Logic". It doesn't mean literally "Business" as in the sense of commerce, but rather distinguishes logic that is specific to the application's functionality from other types of logic such as the GUI logic (controllers) and persistence logic.

Actions serve as the interface between the MVC layer and the Business layer. In a "pure" MVC world, they wouldn't exist - and if there's actually an architectural name for them, I've never seen one. However, in the real world, we want more than just a pretty UI, we want that UI to interact with a wider context, so we include a interface for that purpose.
Mahesh Subramaniya
Greenhorn

Joined: Dec 12, 2004
Posts: 19

Tim Holloway wrote:
Mahesh Subramaniya wrote:Good Explanation Tim!

You're thinking in terms of specifics, but MVC is an abstraction. In MVC, the controllers are components which link the Model and a View. Note that I said "a" View and not "the" View. That's because in a good MVC implementation you can have multiple views of a model, such as, for example, a spreadsheet view and a pie-chart view, both using the same model at the same time.


Tim, A very different thought perspective and clarification.


Thanks to all for discussing this topic in such depth.

Mahesh Subramaniya
Greenhorn

Joined: Dec 12, 2004
Posts: 19

Mahesh Subramaniya wrote:I'm trying to evaluate my design patterns to be used in my architecture. I know Front Controller can be designed to delegate work to respective Helpers. But if I leverage JSF and faces-config.xml, should I still need to worry about the Front Controller pattern, as I understand JSF also does similar work. Correct me if my understanding is wrong.

Thanks.


Today came across this line from http://www.oracle.com/technetwork/articles/javase/javaserverfaces-135231.html
Note that the entry point into the JSF framework is the FacesServlet. It acts as the front controller and handles request processing lifecycle.
 
wood burning stoves
 
subject: Front Controller & JSF
 
Similar Threads
using stateful and stateless session bean together, what happens?
small questions about jsp
Front Controller doubt
What is JSP and how..
forwarding after response has been committed