On Tue, 16 Sep 2003, Sasha Borodin wrote: > Date: Tue, 16 Sep 2003 12:35:22 -0500 > From: Sasha Borodin <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Subject: Re: struts-faces > > Thanks Craig. > > > You can, but the integration library lets you use Struts Actions on the > > back end, creates form beans automatically, and so on. > > Reading through Sun's Web Services Tutorial section on JSF, things are > starting to come into focus: JSF provides functionality that overlaps that > of Struts (my misconception was that JSF was strictly a UI component tag > library). >
Yep ... there's quite a bit of overlap, and JavaServer Faces is FAR more than "a component tag library". > .: Anyone know of a resource that summarizes/contrasts solutions provided by > both frameworks? > I'll throw in a few short comments below, but caution you that this is based on the EA4 release of JavaServer Faces. Things are still evolving rapidly. (My comments ought to have at least a *little* relevance, because I'm both the original author of Struts and the co-spec-lead for JavaServer Faces :-). > i.e.: > -UI Components Struts doesn't really have any notion of components at all (the closest thing is properties of a form bean), while JavaServer Faces has a fairly rich component model that is accessible at both the Java and JSP levels (JSP is not required), supports a separate rendering model (so you can render something like a "select one" control as either a set of radio buttons or a <select> element with one simple change) and is not tied to HTML -- although the default render kit included will be HTML specific. Out of the box, you'll get complex components like a grid and an editable table, and there are already demonstration components for things like trees and menus that (in a Struts world) require additional add-on tag libraries. For people who have existing Struts expertise and/or applications, this is the key value add of integrating JavaServer Faces -- you can use the fancy UI component model without having to change your back-end form beans or actions. > -controller components This is where Struts shines, and I assume you're familiar with that. JavaServer Faces uses a somewhat different abstraction for navigation, and defers the decision of what page to display next to a NavigationHandler that is configured with a set of rules -- the next page is determined by matching rules for: * The page that is currently being displayed * Which Action was invoked (for example, you can have multiple submit buttons on the page that do different things) * Which logical "outcome" was returned by the Action that was invoked -- sort of like how Struts actions return an ActionForward. JavaServer Faces is more flexible in how you organize your processing logic -- you can maintain a Struts-like model of separate "form beans" and "action classes", or you can combine them together (somewhat like how code-behind pages work in ASP.Net). Struts has a couple of framework features (Tiles and the Validator Framework) that are beyond the current scope of JavaServer Faces -- but one advantage of the integration library is that you'll be able to use these sorts of technologies together. > -model components Being presentation frameworks, both technologies are mostly focused on the view and controller. The important part becomes how the presentation tier and model tier object communicate values: * With Struts, you can use property expressions to navigate down a bean hierarchy -- something like: <bean:write name="customer" property="address.city"/> * With JavaServer Faces, this is done with "value reference expressions" that use the same syntax as JSTL EL expressions. The equivalent tag to output a bean property would be: <h:output_text valueRef="customer.address.city"/>: * In both technologies, it's possible to evaluate expressions like this programmatically in your Java code -- with Struts, you use the commons-beanutils package; with JavaServer Faces, you use the ValueBinding API. * With Struts, the framework will automatically create form bean instances for you if you want. If you're using DynaActionForms, you can also preconfigure the properties of the created form bean using the "initial" attribute. * With JavaServer Faces, this concept is extended to support creation of *any* model tier bean (in any scope), complete with configuring the initial properties, using the Managed Bean Creation facility. In the example above, I can configure things such that if the "customer" object does not already exist, a new instance of a configured class will automatically be created, and have its property values also configured based on settings in faces-config.xml. > -Page Flow Neither technology has direct support for page flows. There are add-ons for Struts already; I have no doubt that such things will emerge for JavaServer Faces as well. > -etc. Because Struts is a fairly popular technology, you'll find quite a lot of support for it in development tools. I expect to see the same sort of thing happen for JavaServer Faces; indeed, at JavaOne this year both Sun and Oracle did keynote previews of their upcoming development tools that will be based on JavaServer Faces, and lots of other providers have promised support for it as well. > > Thanks, > > -Sasha Craig McClanahan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]