struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Goodin" <m...@phase.ws>
Subject RE: Struts design flaw -- ActionForms are not true domain objects
Date Mon, 17 Feb 2003 17:43:49 GMT
Just monitoring this thread. I wanted to put my 2 cents in. Being a big
dummy ;-) I was thinking...

Looking at each view technology that exists out there
(JSP,XML,XHTML,WAP,Swing,SWT etc...). We face the reality of having a base
form in which the data is collected and transported. In a markup environment
we usually have a request object that houses all of the form input. The
request also passes around objects which some may use in a jsp page. Others
may use a straight xml/xslt solution which keeps the request a simple query
transport but has to generate objects for creating those pages on the fly.

Anyways, The point being.... struts forms that request into usable objects
for the business-tier to take advantage of. What is the other option? Do we
create Factory classes in our business logic to accomodate every sort of
means of basic data transport out there and data conversion that needs to
happen? Or do we provide an intermediary stage (like struts
ActionServlet,ActionForm,Action) that prepares that data for the biz logic.

Personally, I think Struts handles a type of view quite well(web). I'm not
using Swing in conjunction with struts. But, if I so desired my business
logic classes are freely available to be used in a swing or swt environment.

As far as validation... Struts is NOT trying to accomplish all validaiton.
Some validation can be handled on the Struts side to allow for better
preparation of data and data conversion to the biz logic. Errors that are
passed form the biz logic layer can be captured and displayed to the user if
need be. So validation can still be handled in the business logic.

I could go on and on... but I will end it with a couple comments:

1) Struts handles various issues in an appropriate and thoughtful manner. I
only look forward to struts improving.
2) What technology out there is not breaking someones ideal model? The
reason why we discard one technology for another is that the shortcomings of
one technology become unbearable in comparison to another. I can bet you
that there would be sizeable opponents to Rod Johnson's way of doing things
as well as there are opponents to the way struts does things.

No matter what technology you use you will be disatisfied with it in some
aspect or another. If it's too unbearable for you to use Struts. Then there
are various other frameworks that might serve your project better. :-)

Let's just work on making what we have better. :-D

Brandon Goodin
Phase Web and Multimedia
PO Box 85
Whitefish MT 59937
P (406) 862-2245
F (406) 862-0354
mail@phase.ws
http://www.phase.ws


-----Original Message-----
From: NYIMI Jose (BMB) [mailto:Jose.NYIMI@proximus.net]
Sent: Monday, February 17, 2003 10:10 AM
To: Struts Users Mailing List
Subject: RE: Struts design flaw -- ActionForms are not true domain
objects


> True data binding is generally inflexible and troublesome.
> Having come
> from the VB world many years ago, and its data binding way of doing
> things, I can say that I can't stand it. Having a middle
> ground creates
> more opportunities and power than not having it. I know some
> who still
> do data binding in swing apps, and they end up doing lots of hacks to
> perform things like validation, both simple and complex, and other
> 'process' type of actions. All of this is easy to do with the
> way Struts
> handles things. Taking the data out of a DynaForm once I'm done doing
> simple validation and maybe some pre-processing, then doing a simple

Rod Johnson, recommanded the following :
"Validation code shouldn't be contained in web-tier controllers or any
objects unique to the web tier. This allows the reuse of validation objects
for other client types".

He continued by :

"Validation in the web tier has the severe disadvantage of tying validation
logic(which may be business logic) to the Servlet API and perhaps also to a
web application framework.
Unfortunately, Struts tends to push validation in the direction of the web
tier, as validation must occur on Struts ActionForm objects, which depend on
the Servlet API, and hence *cannot* not be passed into an EJB container and
should not be passed to any business object. For example, validation is
often accomplished by overrinding the org.apache.struts.action.ActionForm
validate method.
I consider this (and the fact that ActionForm objects must extends a Struts
superclass dependent on the Servlet API) to be a major design flaw.

> copyProperties call to take the string version of the data
> and populate
> a 'real' domain object is to easy for me want to give up.

With the framework suggested by Rod Johnson there is no need to make this
copy.
The design deals with domain object.

José.

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


**** DISCLAIMER ****

"This e-mail and any attachment thereto may contain information which is
confidential and/or protected by intellectual property rights and are
intended for the sole use of the recipient(s) named above.
Any use of the information contained herein (including, but not limited to,
total or partial reproduction, communication or distribution in any form) by
other persons than the designated recipient(s) is prohibited.
If you have received this e-mail in error, please notify the sender either
by telephone or by e-mail and delete the material from any computer".

Thank you for your cooperation.

For further information about Proximus mobile phone services please see our
website at http://www.proximus.be or refer to any Proximus agent.


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



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


Mime
View raw message