ErrorsTag

[jh...@inst.strykercorp.com]

I'd like to submit a patch to struts and struts-example to have ErrorsTag
take an String[] of message keys rather than the messages
themselves.  That way all of the i18n code for error messages can be in
one place within ErrorsTag rather than in all of the error generating 
locations.  Do you think it's too late to change that?

-jh

-- 
Jeff Hutchison <jh...@inst.strykercorp.com>
Stryker Instruments, Kalamazoo, MI

Re: ErrorsTag

["Craig R. McClanahan" <Cr...@eng.sun.com>]

"Hutchison, Jeff" wrote:

> On Thu, 15 Jun 2000, Craig R. McClanahan wrote:
>
> > > "Hutchison, Jeff" wrote:
> > > What I've got in the works:
> > >
> > > ValidatingActionForm - new interface
> > > ValidatingActionFormBase - new abstract basic implementation of above
> > > ActionMapping - added inputForm property
> > > ActionMappingBase - added inputForm property implementation
> > > ActionServlet - modify perform to check for instanceof
> > > ValidatingActionForm
> > >
> >
> > A couple of questions and comments:
> >
> > * The ValidatingActionForm interface will extend the ActionForm interface, right?
> >   It only needs to add the validate() method.
>
> Yes.
>
> > * I'm not sure that we really need ValidatingActionFormBase -- it's
> > only one method in the standard interface.
>
> Your probably right, especially since validate() now is so simple.
> I'll take it out.
>

In the example application, there is one scenario where the validate() method could
really use a little more context information -- when you register yourself, and the
system wants to check for that username already being in use.  We've got two options:

* Leave the validate() method with no arguments, and check for this kind of
  thing in the action class itself.

* Pass something (but what?  the servlet context?  the request?) to the
  validate() method so that it can look up what it needs.

I'm tending to think that the first approach is the reasonable one on this topic.

>
> > * Why does ActionMapping need a new property?  Can't we just re-use the
> >   formClass property?  A particular form class can be validating or not, and the
> >   controller servlet will figure that out at runtime with an "instanceof" check.
>
> The formClass property is a class name while the inputForm property is
> a URI that points back to the calling form so we can forward back to
> the original form if validation failed.  Just like the failure
> property in example's ApplicationMapping.
>

Gotcha.  That makes sense.

>
> -jh
>

Craig

Re: ErrorsTag

["Hutchison, Jeff" <jh...@inst.strykercorp.com>]

On Thu, 15 Jun 2000, Craig R. McClanahan wrote:

> > "Hutchison, Jeff" wrote:
> > What I've got in the works:
> >
> > ValidatingActionForm - new interface
> > ValidatingActionFormBase - new abstract basic implementation of above
> > ActionMapping - added inputForm property
> > ActionMappingBase - added inputForm property implementation
> > ActionServlet - modify perform to check for instanceof
> > ValidatingActionForm
> >
> 
> A couple of questions and comments:
> 
> * The ValidatingActionForm interface will extend the ActionForm interface, right?
>   It only needs to add the validate() method.

Yes.

> * I'm not sure that we really need ValidatingActionFormBase -- it's
> only one method in the standard interface.

Your probably right, especially since validate() now is so simple.
I'll take it out.


> * Why does ActionMapping need a new property?  Can't we just re-use the
>   formClass property?  A particular form class can be validating or not, and the
>   controller servlet will figure that out at runtime with an "instanceof" check.

The formClass property is a class name while the inputForm property is
a URI that points back to the calling form so we can forward back to
the original form if validation failed.  Just like the failure
property in example's ApplicationMapping.

-jh

-- 
Jeff Hutchison <jh...@inst.strykercorp.com>
Stryker Instruments Kalamazoo, MI

Re: ErrorsTag

["Craig R. McClanahan" <Cr...@eng.sun.com>]

"Hutchison, Jeff" wrote:

> On Thu, 15 Jun 2000, Craig R. McClanahan wrote:
>
> > jhut@inst.strykercorp.com wrote:
> >
> > > I'd like to submit a patch to struts and struts-example to have ErrorsTag
> > > take an String[] of message keys rather than the messages
> > > themselves.  That way all of the i18n code for error messages can be in
> > > one place within ErrorsTag rather than in all of the error generating
> > > locations.  Do you think it's too late to change that?
> > >
> >
> > This makes a lot of sense to me.  Among other things, it helps in our
> > ValidatingActionForm scenario, where we want a form bean to be able to
> > validate itself and pass back error messages, without knowing anything about
> > the current locale.  I will go ahead and make this change (and also update
> > the same app).
>
> Cool.  I'm currently working on the ValidatingActionForm stuff and just
> about ready to pull everything together.  Do you mind if I convert one of
> the existing forms over to a ValidatingActionForm or do you want me to
> work a new one into the example?
>

I will check in the updates to the error tag (and corresponding changes to the
example app's actions) shortly.

I would like to see the example changed to use ValidatingActionForm wherever it
makes sense.  If you want to go for it, that would be great!

>
> What I've got in the works:
>
> ValidatingActionForm - new interface
> ValidatingActionFormBase - new abstract basic implementation of above
> ActionMapping - added inputForm property
> ActionMappingBase - added inputForm property implementation
> ActionServlet - modify perform to check for instanceof
> ValidatingActionForm
>

A couple of questions and comments:

* The ValidatingActionForm interface will extend the ActionForm interface, right?
  It only needs to add the validate() method.

* I'm not sure that we really need ValidatingActionFormBase -- it's only one
method
  in the standard interface.

* Why does ActionMapping need a new property?  Can't we just re-use the
  formClass property?  A particular form class can be validating or not, and the
  controller servlet will figure that out at runtime with an "instanceof" check.

>
> -jh
>

Craig

Re: ErrorsTag

["Hutchison, Jeff" <jh...@inst.strykercorp.com>]

On Thu, 15 Jun 2000, Craig R. McClanahan wrote:

> jhut@inst.strykercorp.com wrote:
> 
> > I'd like to submit a patch to struts and struts-example to have ErrorsTag
> > take an String[] of message keys rather than the messages
> > themselves.  That way all of the i18n code for error messages can be in
> > one place within ErrorsTag rather than in all of the error generating
> > locations.  Do you think it's too late to change that?
> >
> 
> This makes a lot of sense to me.  Among other things, it helps in our
> ValidatingActionForm scenario, where we want a form bean to be able to
> validate itself and pass back error messages, without knowing anything about
> the current locale.  I will go ahead and make this change (and also update
> the same app).

Cool.  I'm currently working on the ValidatingActionForm stuff and just
about ready to pull everything together.  Do you mind if I convert one of
the existing forms over to a ValidatingActionForm or do you want me to
work a new one into the example?

What I've got in the works:

ValidatingActionForm - new interface
ValidatingActionFormBase - new abstract basic implementation of above
ActionMapping - added inputForm property
ActionMappingBase - added inputForm property implementation
ActionServlet - modify perform to check for instanceof 
ValidatingActionForm

-jh

-- 
Jeff Hutchison <jh...@inst.strykercorp.com>
Stryker Instruments Kalamazoo, MI

Re: ErrorsTag

["Craig R. McClanahan" <Cr...@eng.sun.com>]

jhut@inst.strykercorp.com wrote:

> I'd like to submit a patch to struts and struts-example to have ErrorsTag
> take an String[] of message keys rather than the messages
> themselves.  That way all of the i18n code for error messages can be in
> one place within ErrorsTag rather than in all of the error generating
> locations.  Do you think it's too late to change that?
>

This makes a lot of sense to me.  Among other things, it helps in our
ValidatingActionForm scenario, where we want a form bean to be able to
validate itself and pass back error messages, without knowing anything about
the current locale.  I will go ahead and make this change (and also update
the same app).

In terms of timing, I consider Struts to be pre-version-1 so that the APIs
are pretty much in flux.  Once we do a formal 1.0 release we will need to
worry more about the impacts of non-compatible changes.

>
> -jh
>
> --
> Jeff Hutchison <jh...@inst.strykercorp.com>
> Stryker Instruments, Kalamazoo, MI

Craig