struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@apache.org>
Subject Re: Theoretical debate
Date Fri, 09 Jul 2004 21:45:46 GMT
Hookom, Jacob wrote:

>You threw me for a loop with replying so late to that email--
>
>It just comes down to giving the developer the ability to scale their own
>layers with JSF like you said below.  If I want ActionForms, then I will
>have JSF update request/session scope beans that are only for the view.  If
>I want something simpler, then I can have JSF update my business beans
>themselves.
>
>JSP->View Logic/Beans->Business Logic/Beans
>JSP->Business Logic/Beans
>
>PS: Craig, did you get my email to Ed Burns and yourself about a new, faster
>JSF-specific EL implementation for JSF RI?
>
>  
>
I did indeed.  I'm sure Ed will look at it next week, after Sun returns 
to operation from our shutdown this week.

>Best Regards,
>Jacob Hookom
>
>  
>
Craig


>-----Original Message-----
>From: Craig McClanahan [mailto:craigmcc@apache.org] 
>Sent: Thursday, July 08, 2004 7:35 PM
>To: Struts Users Mailing List
>Subject: Re: Theoretical debate
>
>Hookom, Jacob wrote:
>
>  
>
>>Look at JSF, do you have actions? No, JSF just updates your POJO beans and
>>calls methods on them.  Why have an ActionForm or have to create all of
>>these Actions that are simply getter/setter adapters?  Please don't be too
>>quick to retort to my supposed anti-struts mindset, but there are other
>>frameworks out there that allow direct interaction with my business objects
>>and don't require a heck of a lot of framework specific coding.
>>
>> 
>>
>>    
>>
>(Coming into this discussion late, but figured that my experience on 
>both the Struts and JSF side of things might provide some illuminating 
>food for thought :-)
>
>It's instructive, first, to go back to the beginning of Struts 
>development (just over four years ago), and recall why an ActionForm 
>exists in the first place.  The only reason we created that abstraction 
>was to deal with some pesky real world problems in designing webapps ... 
>primarily dealing with conversion (where we really punted ... see 
>below), validation, and little things like maintaining the state of 
>checkboxes.  Because Struts doesn't have any "user interface component" 
>concept, dealing with those things had to go somewhere -- and a common 
>abstraction at least made it easy to understand.
>
>Therefore, the recommended design pattern for a Struts based app becomes:
>
>- An ActionForm per input <form>, normally with
>  String-based properties (so you can redisplay
>  invalid input the way users expect you to).
>
>- A set of validation rules that are applied for you
>  on the server side, and optionally also on the
>  client side.
>
>- If a validation error occurs, Struts takes care
>  of redisplaying the page (with error messages)
>
>- If validation succeeds,  the application Action
>  is responsibe for performing conversions of the
>  String valued things in the ActionForm to match
>  the underlying model data types, typically by
>  copying them in to DTO/VO type objects and
>  passing them to business logic (although, as others
>  have pointed out, lots of Struts developers have
>  skipped this extra layer).
>
>With JSF, the component model takes care of all the responsibilities 
>that Struts uses an ActionForm for, so you don't need one any more.  
>Indeed, I anticipate people will choose one or more (they aren't 
>mutually exclusive) of at least three different styles for building 
>JSF-based webapps:
>
>(1) You can bind individual *components* to backing bean properties,
>     similar to how ASP.Net "code behind files" work.  This will
>     be most comfortable to VB developers, and is useful when
>     you need to programmatically modify component properties.
>
>(2) You can bind component *values* directly to properties in your
>     backing bean, and then provide the business logic as action methods
>     in the same class.  Because the components take care of conversion,
>     you're free to use model-oriented data types for such properties,
>     so you don't need to worry about explicit conversion any more.
>     This style will appear to Struts developers like a combination of an
>     Action and an ActionForm in the same class, and will also appeal to
>     the crowd that likes O-O encapsulation :-).
>
>(3) You can bind component *values* directly to properties on a VO/DTO
>     object, and bind action events to methods on a separate bean that will
>     either perform the logic directly or delegate to a business logic 
>class.
>     This style will feel more like traditional Struts separated 
>ActionForm and
>     Action classes, but the Action won't have as much to do.  It's also 
>a great
>     way to build a webapp on top of existing application infrastructure 
>that
>     provides resuabe VO/DTO and business logic classes already.
>
>I believe that all three approaches are valid -- which one you take for 
>a particular application function depends on your use case for that 
>function.  You don't have to be exclusive, either.  Combine them where 
>it makes sense.
>
>Craig McClanahan
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>  
>


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


Mime
View raw message