Perhaps this link to Craig's blog will help clarify things: http://blogs.sun.com/roller/page/craigmcc/20040927#struts_or_jsf_struts_and
Matt
Abrams, Howard A wrote:
Thanks again Kevin, but the bullet points from the article don't state why I would want to use Struts w/ JSF. With the exception of the quote about the controller being 'powerful', they just list why JSF is good. I know why JSF is good, why is Struts plus JSF better?
-----Original Message----- From: Kevin Bridges [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 11:13 AM To: Struts Users Mailing List Subject: Re: JSF or Struts w/ JSF (again)
From the article:
Why integrate the trinity? As the JSP and the related specifications mature, new standards like JSF and the JSP Standard Tag Library (or JSTL, which uses simple tags to encapsulate the core functionality common to many JSP applications) are emerging. Following are some of the advantages to using the new technologies as an integrated whole:
* Cleaner separation of behaviors and presentation. With the separation of tag, renderer, and component, the roles of page authors and application developers in the development cycle become better defined.
* Changing the presentation for a component does not have an avalanche effect. Now you can easily just change the renderer. In the traditional MVC model, since this separation did not exist, any change in tags needed changes to the business logic as well. Not any more.
* Renderer independence. Or restated, protocol independence by reusing component logic for multiple presentation devices with multiple renderers. The ability to use different renderers eliminates the need to code the entire presentation tier for specific devices.
* A standard for assembling and reusing custom components. JSF thinks beyond "forms and fields" and provides a rich component model for rendering custom GUI components. Using JSF you can customize the way each component looks and behaves in a page. Developers also gain the ability to create their own GUI components (like menus and trees), which can easily be included in any JSP page with simple custom tags. Just like the Java front-end GUI components provided by AWT and Swing, we can have custom components for our Web pages that use their own event handlers and have customizable appearances. This is GUI nirvana for the Web tier!
Struts is a framework that already possesses a large customer base. Many IT departments have recognized the value of this MVC framework and have been using it for quite a while. JSF doesn't possess the equivalent of Struts's powerful controller architecture, as well as its standardized ActionForm and Actions (with their declarative capabilities). When you integrate Tiles into the mix, you give yourself the ability to reuse and change corporate layouts in a seamless manner.
The challenges of migrating JSF-enabled Struts applications are two-fold. First, Struts tags are not JSF-compliant. In other words, they do not extend the UIComponentTag as mandated by the JSF specification, therefore, JSF cannot interpret and associate UIComponent and Renderers with them.
Second, there is no link between the FacesServlet and Struts RequestProcessor. In a Struts application, the RequestProcessor manages the show with the callback methods into ActionForm and Actions classes. Getters and setters for ActionForm properties and validate() are the callback methods in the ActionForm. For Action, execute() is the callback method. Unless the RequestProcessor gets invoked, the callback methods in Struts ActionForm and Actions classes do not get a chance to invoke the business logic.
On Tue, 2 Nov 2004 13:57:56 -0500, Abrams, Howard A <[EMAIL PROTECTED]> wrote:
-----Original Message----- From: Kevin Bridges [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 10:40 AM To: Struts Users Mailing List Subject: Re: JSF or Struts w/ JSF (again)
I found this article to be useful in addressing some of your
questions:
http://www-106.ibm.com/developerworks/java/library/j-integrate/
Thanks for the pointer Kevin. The article does a good job explaining _HOW_ to integrate the two, but (and perhaps it's because I don't
know
enough about Struts), it didn't seem explain _WHY_ I would want to integrate the two. The only semi-concrete reason/feature I found in
the
article was this:
"JSF doesn't possess the equivalent of Struts's powerful controller architecture, as well as its standardized ActionForm and Actions
(with
their declarative capabilities)." [sic]
Can someone explain what makes the struts controller so 'powerful'
in
relation to JSF? What about Struts' ActionForm and Action and their benefit over JSF actions and beans?
On Tue, 2 Nov 2004 13:22:15 -0500, Abrams, Howard A <[EMAIL PROTECTED]> wrote:
Hi everyone,
For a new project, I'm planning on using JSF. The questions I
need
to
answer are:
What will Struts add if I use it together with JSF? Does it add
missing
functionality? Is there a good design pattern that JSF alone
does
not
enforce? Are there common problems that are easier to solve
using
the
combination? (For the moment, ignore the validation framework
and
tiles)
I've been searching the internet and the list archives for
answers.
The
only concrete feature I found was message from Craig saying that
because
all request processing is routed through a common controller,
Struts
helps implementing things such as authentication and logging. Is this significantly easier that decorating the viewHandler or
actionListener
in JSF? Isn't that what struts-faces does anyway? (the message I'm referring to can be found here:
http://mail-archives.apache.org/eyebrowse/ReadMsg?
[EMAIL PROTECTED]&msgNo=112850)
I've got a fairly good handle on JSF, but I'm not proficient
with
Struts. I'm hoping some of the seasoned Struts developers reading this
can
point
out the benefits I've missed.
Thanks in advance, Howard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
