struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Toni" <t...@fdplus.com>
Subject RE: REPOST: Forcing the ActionForm to populate a field before the other
Date Thu, 02 Jan 2003 19:52:01 GMT
Thank you Rick, James and Craig for your inputs.  The answers is exactly
what I was looking for in order to get off my lazy a** and break things
apart.

I was trying to set a quantity field do indicate how many child forms to
display in one step without using an action with the nested tag lib.

Happy new year.

-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org] 
Sent: Thursday, January 02, 2003 11:56 AM
To: Struts Users Mailing List; developer@fdplus.com
Subject: Re: REPOST: Forcing the ActionForm to populate a field before
the other




On Thu, 2 Jan 2003, Toni Charlot wrote:

> Date: Thu, 2 Jan 2003 10:10:32 -0500
> From: Toni Charlot <developer@fdplus.com>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>,
>      developer@fdplus.com
> To: struts-user@jakarta.apache.org
> Subject: REPOST: Forcing the ActionForm to populate a field before the
>     other
>
> I would like to have a setter method called before another.  What's 
> the best way to do that in the ActionForm

There are no guarantees on the order that the setters are called.  This
is for two reasons:

* There is no rule in the HTTP or HTML specs defining the order
  in which the request parameters are sent, so it's totally up
  to the client.  And they really do operate differently.

* There is no rule in the servlet spec saying that the input order
  has to be preserved, so it's totally up to the container to decide
  how to implement this.  And they really do operate differently.

More fundamentally, though, the only reason that the setter order would
matter is if there are side effects (setting one property affects the
semantics of setting a different one).  Designing your form beans in
this way is a very poor architectural decision -- the whole point of a
form bean is to simply represent the input values that the user actually
entered on the form.  Any functionality that tries to assign "meaning"
to these inputs should be done in business logic (which can pull data
out of the form bean in any order that you need), not in the form bean
itself.

>
> Thank you.

Craig McClanahan



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




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


Mime
View raw message