You need to remember where, in a sense, you are, Howard. A lot of people, obviously, have invested a lot of time and energy into Struts based applications. With the advent or potential of JSF, so need to start to think about moving over. So, the merger of the two technologies here are not for people starting out but rather with a substantial investment in Struts to start. I think you have gotten good advice here. If you are starting out, as you apparently are, you need to choose, probably, one or the other. One the one hand, with your limited knowledge of the area, you will probably, I would GUESS, be best served by Struts because it has a lot of things that you, I think, would have to build for JSF. On the other hand, JSF will potentially be the future, and you might want to jump on board now.
Michael On Tue, 2 Nov 2004 18:23:28 -0500, Abrams, Howard A <[EMAIL PROTECTED]> 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] > > -- "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
