struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hookom, Jacob" <Jacob.Hoo...@redline.mckhboc.com>
Subject RE: Theoretical debate
Date Fri, 09 Jul 2004 14:02:26 GMT
I've been working on an example with AOP on the Controller and View Objects.
I have a set of Objects that support the view with controller methods.
These methods are supported by aspects to handle exceptions, caching, and
chaining of method calls.  In result, it's taking an application layer and
providing compile time support for the same kind of features that Struts
provides-- but slightly faster and framework independent with AspectJ.

-----Original Message-----
From: Mike Duffy [mailto:mduffy_lists@yahoo.com] 
Sent: Thursday, July 08, 2004 11:10 PM
To: Struts Users Mailing List
Subject: Re: Theoretical debate

One aspect of JSF which I find troubling is, "With JSF, the component model
takes care of all the
responsibilities that Struts uses an ActionForm form, so you don't need one
any more."  

Most of the JSF examples I've studied use method (2) from Craig's list
below: "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."  As an example of this approach
see, Developing Web
Interfaces with JSF,
http://www.fawcette.com/javapro/2004_01/magazine/features/cschalk/default.as
px 

IMHO, mixing business logic in the backing bean is not a great design. I
like the clean separation
provided by the Struts action class. 

Method (3) from Craig's list below seems like a viable solution: "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."

I've read most of the major articles on JSF.  I have not seen method (3)
implemented as an
example.  Does anyone have a link that they can send showing the
implementation of method (3)? 
Does anyone know if there will be a reference implementation for JSF using
method (3)?  I think it
would increase the acceptance of JSF in the Struts community if such a
reference implementation
was available.

Thanks.

Mike


--- Craig McClanahan <craigmcc@apache.org> wrote:
> 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
> 
> 


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---------------------------------------------------------------------
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