You define the common validations, and inherit them into 2 seperate definitions to call from the 2 seperate actions.
I am speaking only on here-say though, since I haven't had the opportunity to check this out yet! But it seems to me to be an elegant way of avoiding the ValidatorActionForm.
And as you say, the 'deprecation' is not in the code, yet (if ever). But if the inheritance works, then why not?
On 04/20/2004 08:10 PM Joe Hertz wrote:
Hadn't heard that myself, but I'm using the 1.2 Nightly and have no deprecation warnings for DynaValidatorActionForms. I thought it was just that formsets would inherit the declarations "above" them.
Anyway, I don’t see how it would make ValidatorActionForms unnecessary.
If I have a FormX which is FormY with field A removed, field B added,
and (most importantly) field C validated differently, how is inheritance
going to help me?
Since I'd be calling them from different actions anyway, the way I'd do it now is to use a [Dyna]ValidatorActionForm form with everyone the fields defined and different rules defined for each action.
-----Original Message-----
From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 1:16 PM
To: Struts Users Mailing List
Subject: Re: Validator Framework
I thought ValidatorActionForm was going to be deprecated because the new form configuration functionality allows validation form inheritance and therefore makes the 'definition by action' redundant, since it becomes totally simple to define new forms without repeated heaps of fields.
On 04/20/2004 04:39 PM Joe Hertz wrote:
Based on what Hubert said, the confusion I initially
encountered was
180 from what apparently is typical. I thought everything wanted to know about an Action, html:form's, etc :-/
I think the moment a form class got created whose name
didn't end with
"ActionForm", problems were bound to show up..
Anyway, The logic I think currently goes like this-
[Dyna]ValidatorActionForms validate based upon the Action. [Dyna]ValidatorForms validate based upon the Form.
What they should have been in the first place IMHO-
[Dyna]ActionValidatorForm and [Dyna]FormValidatorForm
Or (yeah, cumbersome but more consistent with everything
else being an
"XXXActionForm"):
[Dyna]ActionValidatorActionForm and [Dyna]FormValidatorActionForm.
But since they werent created that way, with deprecations,
this would
be REALLY CONFUSING(tm), so I'd suggest replacing "Validator" with "Validation" in all of the above suggestions :-)
-Joe
-----Original Message----- From: Hubert Rabago [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 9:41 AM To: Struts Users Mailing List Subject: Re: Validator Framework
--- Joe Germuska <[EMAIL PROTECTED]> wrote:
Let's try a quick poll -- are these better names?
NameDynaValidatorForm for DynaValidatorForm
PathDynaValidatorForm for
DynaValidatorActionForm
If so, we could deprecate the old names and put in new ones.
If these aren't good, people are encouraged to suggest
better names.
You can also consider changing only the
DynaValidatorActionForm, since IMHO that's the one that causes the confusion, and DynaValidatorForm already works the way other form beans do.
Hubert
__________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
