When reading HFSJ, it talked about having a Front Controller design pattern, where a single servlet (controller) is tasked with handling all requests that come in.
It then talks about how Struts is a framework with this all built in, and I notice that the packages are from Apache.
Finally, I started reading about JSF through "JavaServer Faces Programming" by Budi Kurniawan (sadly out of date) and noticed a similar pattern - a single Faces servlet that requests are channelled towards.
If I were to say that "JSF was Sun's answer to Struts", would I be far out?
JSF wasn't so much designed to be a "Sun version of Struts" as it was to address some of the uglier aspects of Struts. And to make web app design more of the drag-drop-drool process it is in .Net.
Struts is technically known as a "Model 2" architecture. It's based on the old MVC paradigm, but no webapp can truly implement MVC, since a webapp cannot asynchronously update a view should the model be changed (HTTP is strictly client-request/server-response with no server "push").
The problem, as Craig McC himself pointed out, is that Struts requires a rather large number of loosely-interconnected objects in order to get simple things done. JSF reduces the number of objects. Instead of multiple action classes, a Form Bean, JSP and config wiring, you only have a simple JavaBean, JSF page, and config wiring. Some people have attempted to make a single action class handle multiple phases of the process, but that's even gnarlier than having multiple action classes.
And since the backing bean can constructed with no implicit knowledge of the container (unlike Struts objects, which have to be derived from Struts base classes), you can generally do unit-testing of JSF backing objects via straight JUnit-style testing without having to go through the cumbersome and time-consuming process of setting up and running a web container framework.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Nov 11, 2006
Hi John and Tim,
Thanks for your replies - they make it a lot clearer.
JSF was Sun's answer to the fact that the Servlet and JSP API was awesome, but it didn't provide a framework for developing applications. Things like state management, front controller design, error handling and MVC development was very much left up to the end user, and the Servlet & JSP API world was just begging for one.
It's a hypothetical statement, but I'd say that if Struts never happened, Sun would have still come up with JSF, because a unified development framework had always been needed.
JSF also has a richer life cycle within the default http mechanism of a request and a response, which allows the developer to perform different actions and plug in code in many places. It is a components based framework, which gives the ability of creating reusable presentation components in the same fasion that GUI applications have lifecycle and listeners attached for different events. Plus with the popularization of AJAX these components can/are even reacher, making web application not so mundane andboring but more responsive to user input. All of this still uses some of the nice stuff implemented in Struts, I mean the abstaraction of the view from the underlying system data etc., but it has a lot more breath in my mind, if you had to compare them I would say JSF goes a step further than Struts, you should be looking at Tapestry not Struts I think....