struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
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
>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

>-----Original Message-----
>From: Craig McClanahan [] 
>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 
>     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 
>     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:
>For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message