>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]
