On Mon, 11 Nov 2002, Karr, David wrote:
> Date: Mon, 11 Nov 2002 12:22:44 -0800
> From: "Karr, David" <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: RE: Unclear semantics on form use for "wizards"
>
> This may seem far out, but what if the "reset" functionality could be
> entirely specified in the "form-bean" element?
>
You could make a case that it already is :-).
If you use DynaActionForm or DynaActionValidatorForm, the default reset()
method has well-defined semantics already (including the fact that it sets
boolean properties to false). In addition, it supports setting the value
to which most properties are set with the "initial" attribute on
<form-property>. The only cases you typically need to override reset() in
this case are for mapped properties -- the initial expression supports a
subset of Java's array initializer syntax for array based properties:
<form-property name="statuses" type="java.lang.String[]"
initial='{ "foo", "bar" }'/>
The missing link for a multi-page form is some way to tie which page got
submitted to the set of properties that live on that page (and therefore
need to be reset.
Craig
> For instance, the "reset" element could contain a set of elements named
> "test", each of which would have attributes "field" and "value". The
> "test" element would have "field" subelements, which take a "name"
> attribute, and an optional "value" attribute.
>
> The "reset" and "test" elements would work like a "switch" statement (or if-elseif).
> It would "evaluate" each of the "test" elements, comparing the value of the "field"
>(which has to be a "form-property" of the form) with the "value". If they are equal,
>then the encapsulated "field" elements would all be "reset", either to a standard
>"zero" value for each type, or to the optional "value" attribute of the "field"
>element.
>
> The names of these elements and attributes aren't important, but the structure is.
>This solution would require no application-specific subclasses.
>
> > -----Original Message-----
> > From: Jason Rosen [mailto:JRosen@;yvimail.com]
> > Sent: Monday, November 11, 2002 12:05 PM
> >
> > The reset() method lives in the ActionForm class. In order
> > to have reset() evaluate what to do means overriding reset()
> > by subclassing ActionForm (or some child of ActionForm). So
> > to have all these different reset() evaluations means having
> > different ActionForm subclasses.
> >
> > Then if you wanted to use a different ActionForm
> > implementation like DynaActionForm or DynaValidatorForm, you
> > start duplicating your reset() code around because Java
> > doesn't allow for multiple inheritance. This is the mess I
> > started finding myself in - some of my Actions were using
> > DynaActionForms, some were using DyanValidatorForms, and some
> > were ActionForms but I needed similar reset() functionality
> > in all of them. So the reset() code was getting hard to maintain.
>
> --
> To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
