[prev in list] [next in list] [prev in thread] [next in thread] 

List:       struts-user
Subject:    Re: struts-faces
From:       Adam Hardy <ahardy.struts () cyberspaceroad ! com>
Date:       2003-09-17 11:14:27
[Download RAW message or body]

Hi Craig,
I remember a while ago in one of these architecture- theme emails you 
discussed the OO nature of struts & it had been said that the 
action-form class and the action class broke the OO encapsulation 
principle, by having data in one and functionality in another. You said 
if you were going to design struts again, you would probably address this.

Does JSFaces bring these two closer together? Or is this an area where 
Faces is not involved? I see you say that in a combination of struts & 
Faces, you would still use actions and forms.

The reason I ask is that I just had a hard time redesigning a page 
because my initial design failed. The page allows an edit of one parent 
object, while showing a list of its child objects with 
move-to-new-parent / delete controls. I got in a mess initially over 
whether to use the parent or child's form and action for the child 
operations.

Fortunately I solved it nicely by nesting the child objects in the 
parent form, and passing the whole lot to the parent's model, which then 
worked out if it needed to call the child's model for any operations.


Adam

On 09/16/2003 09:30 PM Craig R. McClanahan wrote:
> On Tue, 16 Sep 2003, Sasha Borodin wrote:
> 
> 
>>Date: Tue, 16 Sep 2003 12:35:22 -0500
>>From: Sasha Borodin <sasha@whoissasha.com>
>>Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
>>To: Struts Users Mailing List <struts-user@jakarta.apache.org>
>>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: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
> 
> 

-- 
struts 1.1 + tomcat 4.1.27 + java 1.4.2
Linux 2.4.20 RH9


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]