struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stan Baranek <st...@gene.COM>
Subject Re: A thought about Simplifying the Action Form
Date Thu, 29 Aug 2002 04:48:13 GMT
If I understand you your suggesting extending Struts beyond presentation 
to a DO which is a representation of your data model.
I think by providing this sort of linkage from the HttpRequest all the 
way to your RemoteInterface? - you would inherantly be forcing your 
presentation logic into the business logic.  You would end up designing 
your presentation as a mirror of your database model or even worse: 
visa-versa.  This would make a very inflexable system.  

I have enough trouble changing all of my ActionForm elements into 
String[] - I think everything in the database would be varchar2(100) (=))


Brandon Goodin wrote:

>A few thoughts about the Action Form:
>1) ActionForm is a view object
>2) ActionForm is populated by ActionServlet mapped to request parameters
>3) ActionForm should NOT be passed into the Business Logic Tier but should
>stay in the application Tier
>4) ActionForm should NOT be used as a Model Bean.
>Being as these are true and it sometimes seems to cause extra coding to
>translate form values to beans. In other words. When I write a form and it
>contains values that need to be passed to a bean that is then passed to a
>business object. The process involves the following:
>1) Write ActionForm to collect request (data or use DynaActionForm)
>2) Write a model bean that will receive some or all of the data from the
>3) Use BeanUtils within an Action class to transfer values from bean to bean
>4) Pass bean to business object
>My thoughts here are around the ActionForm using beans instead of it's own
>getters and setters. Is there a reason why we don't have the ActionForm
>instantiate beans to be populated. That way those beans can easily be
>extracted from the ActionForm and passed into the business tier. The
>ActionForm could be configured to instantiate and populate certain beans. It
>would be nice to allow for multiple beans to be configured and if the beans
>have a common setter and getter then both instantiated bean setters will be
>populated with request data. Once the beans are populated with request info
>those same beans can be passed into a business tier using the Action class
>or they can be passed back to the view wrapped with the ActionForm. I know I
>am thinking simplistic at this point. But, I think the idea has some sound
>qualities. Maybe this is already implemented and I am just off my rocker or
>maybe it just sucks. I would be interested to hear any thoughts on this. So
>the process would go something like this:
>1) Write model beans
>2) Configure ActionForm to populate certain model beans with request data
>3) Allow for validation of values and any other ActionForm methods to be
>4) pass ActionForm with associated beans onto Action class or return to view
>with errors
>5) use Action class to extract beans from ActionForm and pass them into
>Business Tier
>This thought was spawned during a discussion with a colleague regarding
>passing ActionForms into the business tier. I felt it was a bad idea because
>it is tying you biz tier too tightly to the app tier. But his rebuttal was
>that the alternative was that we wind up coding more and gaining very little
>(i.e. writing identical code just to populate a form then pass that value to
>a bean). How often are we going to be running this outside webapp using
>struts, anyways?
>I know there is DynaActionForm but I have also heard there are some
>shortcomings on it. What are those shortcomings? The issue here seems to be
>the extra coding. I know the combo of the DynaActionForm and BeanUtils
>allows for a sort of what I am talking about. You only have to write the
>model bean then use BeanUtils to populate it with the DynaActionForm values.
>Yet, I have also tried to run DynaActionForm side by side with Validator and
>I have run into problems. Anyways, it just seems more appropriate to use
>concrete Bean classes and that is why I am providing the aforementioned
>Any thoughts?
>Business Tier - contains model beans and business logic
>Application Tier - Struts Controller and data marshalling
>Web Tier - Application Server
>Brandon Goodin
>Phase Web and Multimedia
>P (406) 862-2245
>F (406) 862-0354
>To unsubscribe, e-mail:   <>
>For additional commands, e-mail: <>

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

View raw message