A thought about Simplifying the Action Form

[Brandon Goodin <ma...@phase.ws>]

Greetings,

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
ActionForm
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
performed.
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
idea.

Any thoughts?



Definitions:
-----------------------------
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: A thought about Simplifying the Action Form

[Stan Baranek <st...@gene.COM>]

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) (=))

Cheers,
Stan

Brandon Goodin wrote:

>Greetings,
>
>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
>ActionForm
>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
>performed.
>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
>idea.
>
>Any thoughts?
>
>
>
>Definitions:
>-----------------------------
>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:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>  
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Calling all design patterns

[Brandon Goodin <ma...@phase.ws>]

Greetings,

I just wanted to put the request out to all you creative thinking
struts-mongers. A few of us are endeavoring to put together a suggested
design patterns for struts. If you have any good working design patterns you
are using with struts then please post em or provide a link to some
documentation. It would be good to hear what is being done. Ted has said he
will shepherd the effort... So, all ideas will be cleared (I assume) through
him before becoming an official design pattern.

Looking forward to getting the low-down,
Brandon Goodin
Phase Web and Multimedia
P(406)862-2245
F(406)862-0354
http://www.phase.ws


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>