struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Murray" <GMur...@edgewater.com>
Subject RE: Use of DynaActionFormClass
Date Thu, 23 Jan 2003 18:10:39 GMT
Thanks for the pointer in that direction.  I tried it and it works, although I'm still not
psyched about having one form bean that must contain all parameters that need to be passed
from any one page to any other.

I'll stick with this unless I can think of something better, I guess.  I would prefer to use
the DynaActionFormClass solution I described below because it's a little clearer regarding
what form bean (i.e. data fields) are used by each action, but it scares me a bit to use a
class that is supposed to be only "internal".

Thanks again!

GM

-----Original Message-----
From: Robert Taylor [mailto:rtaylor@mulework.com]
Sent: Thursday, January 23, 2003 7:50 AM
To: Struts Users Mailing List
Subject: RE: Use of DynaActionFormClass


> The problem here is that for 
> some fields, I may want to do validation sometimes, but not all 
> the time, but using the same form bean for all actions would 
> require that if validation is set for a field, then it's always 
> validated.
DynaValidatorActionForm allows validation to be bound to
the path and not the form name.


robert


> -----Original Message-----
> From: Greg Murray [mailto:GMurray@edgewater.com]
> Sent: Thursday, January 23, 2003 9:32 AM
> To: struts-user@jakarta.apache.org
> Subject: Use of DynaActionFormClass
> 
> 
> I mistakenly posted this to the struts-dev list last night - it 
> belongs on this list since it doesn't have anything to do with 
> development of Struts.  For those of you on that list as well, I 
> apologize for you seeing it twice.
> -----------------------------------
> Hello,
> 
> Currently I'm working on an Struts application that has a tree 
> control for navigation on the left side of the page, and the rest 
> of the page is taken up by the actual body content - no frames 
> are used for the layout, just CSS, so it is actually one single 
> page.  My plan was to have a JavaScript function run each time 
> the user clicked on a link in the tree which would set the values 
> of an HTML form (lets call it navigationForm), then submit the 
> form.  One of the fields of the HTML form would contain the 
> Struts action mapping (lets call the field actionMapping) which 
> was to be invoked for the tree link.  All tree links would use 
> the same form, and all pages would contain this form.  The action 
> that is invoked by this form submission (call it 
> navigationAction) would be responsible for looking up 
> actionMapping, and forwarding on the request to the action 
> denoted by actionMapping.  I should also note that I'm using 
> dynamic form beans.
> 
> My problem is that many of the actions to which I want to forward 
> are expecting their own form bean, not the one that was submitted 
> for navigationForm.  As far as I can tell, I have two options:
> 
> 1.  Have all forms in my application use the same form bean, so I 
> can just pass it around without having to worry about different 
> actions using different form beans.  The problem here is that for 
> some fields, I may want to do validation sometimes, but not all 
> the time, but using the same form bean for all actions would 
> require that if validation is set for a field, then it's always 
> validated.  Also, for some reason, this solution just doesn't 
> "feel" right to me.
> 2.  Create a DynaActionForm in navigationAction for the form 
> related to the action to which I want to forward, and fill it 
> with any matching properties from navigationForm.  The problem 
> here is that I'd need to instantiate the new DynaActionForm using 
> the DynaActionFormClass, which the documentation expressly says 
> is really only an internal class, implying that it might change 
> without warning.
> 
> So, my questions to the list are:
> 1.  Is solution #2 workable, and is it kosher to base my 
> implementation on the use of DynaActionFormClass?
> 2.  Is there a better way to get around this form problem that 
> I'm just not seeing?
> 
> Sorry for the wordiness, but that was as concise as I could 
> explain the problem.
> 
> Thanks very much for any insight anyone can offer.
> 
> Greg Murray
> 
> --
> 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>


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