Howard, take a look at McClannahan's blog entry here: http://blogs.sun.com/roller/comments/craigmcc/Weblog/struts_or_jsf_struts_and
You also might be interested in this article: http://svn.apache.org/viewcvs.cgi/*checkout*/struts/trunk/contrib/struts-shale/README.html He hints at the future of web application development and architecture using JSF, Struts and Spring. I haven't used JSF yet, but am currently looking at it for future projects. Hope this helps you some. robert > -----Original Message----- > From: Abrams, Howard A [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 02, 2004 6:23 PM > To: Struts Users Mailing List > Subject: RE: JSF or Struts w/ JSF (again) > > > > 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]
