Re: Validating bean properties (WAS: Re: Stupd question aboutStruts and EJB.)

[Nick Pellow <ni...@cortexebusiness.com.au>]

Martin, 


martin.cooper@tumbleweed.com wrote:
> 
> Actually, the plan is to build exactly this type of validation into Struts
> 1.1. In particular, I am hoping to incorporate it into the automated bean
> creation tool, one way or another.

Yup, I minutes after my lost post, I received the post for Volunteer for
Validation
Framework. Wish I had read that first! The validation stuff sure could
be interesting.

> The idea is to define your bean(s) in an XML file, and have the tool
> generate the actual bean code for you. When you define a bean, you can
> specify its type, along with some other validation rules (yet to be
> determined). The tool will create a validate() method, and that method will
> populate ActionErrors as appropriate.

> My original thought was to generate code based on the validation rules.
> However, David Winterfeldt has written an interesting validator that runs
> off an XML spec directly. This may be a better approach, in that you can
> modify the rules later without recreating the bean, among other things.

I was considering an approach where coders wrote validation code in Java
(we all know java!)
yet the Struts framework executed it. You would extend or implement a
common java class/interface defining a single method, 
public ValidationErrors validate();  say.
That is then mapped to the form field in an xml file somewhere.

Struts, however could ship all the standard validations (such as Strings
to ints)
together.

It is something I have not given much thought to yet, but would be
interested in
exploring further.


> I'm not sure how this will all fall out in the end, but I will be very
> surprised if Struts 1.1 does not include ways of automating the creation of
> form beans, and ways of specifying validation rules without writing code.
> There are several people interested in working on each of these topics, so
> I expect lots of interesting discussion on each and on how to integrate them.

Sounds great!


> Martin Cooper
> Tumbleweed Communications
> 
> At 02:46 PM 2/28/01 +1100, Nick Pellow wrote:
> >Martin,
> >
> >martin.cooper@tumbleweed.com wrote:
> > >
> > > At 11:17 AM 2/28/01 +1100, Nick Pellow wrote:
> > > >I am very new to struts as is, but as I far as I can tell from reading
> > > >the implementation of the above method,
> > > >the ActionForm can only have String properties. Is this correct?
> > > >
> > > >If so, it would be nice if the ActionForm could support types other than
> > > >String and the
> > > >struts engine would convert these in a similar fashion as Ant does to
> > > >the attributes in the xml build file.
> > >
> > > Actually, Struts will attempt to convert values as it populates a form
> > > bean. This is done in BeanUtils.populate(), which is called right at the
> > > end of RequestUtils.populate().
> >
> >Ooops, thats what I was looking for but did not find.
> >
> > > However, the problem is what to do if it
> > > can't be converted. For example, if I define a form bean property as an
> > > int, and the request contains "abc", what should Struts do?
> >
> >Struts could create an ActionErrors object with an ActionError for each
> >conversion error.
> >If an error does get raised at that early stage, then one will no doubt
> >be raised later on
> >in the Action. The difference is that the coder has to
> >a) check for the conversion error again,
> >b) raise an error again.
> >It also means that checking for such user mistakes is spread across
> >mulitple layers in the application
> >and also across multiple components within the system. I think it would
> >be nice to centralize
> >such type checking in one part of the system.
> >
> >
> >The error message strings could be defined in a similar fashion to
> >errors.header and errors.footer.
> >Maybe something like:
> >errors.conversion.NumberFormatException=You must enter a number for the
> >{0} field, not {1}.
> >
> >Then when Struts comes across a type error, it raises the error then and
> >there, using a resource
> >such as the one above to report to the user.
> >
> >As mentioned earlier in this thread this option could be configurable in
> >Struts as it may not
> >always be desirable.
> >
> > > In 1.0, it will set the property to a (configurable) default value, but
> > > that's not a good solution when there's no obvious candidate meaning
> > > "invalid" (e.g. for a boolean). It also destroys the original user input,
> > > so when validate() fails and returns the user to the input form, you can no
> > > longer display to them the mistake they made. (By default, in the situation
> > > I described above, the user would see "0" where they entered "abc".)
> > >
> > > So it's really best if form bean properties are all strings. What you *can*
> > > do, though, is have your validate() method check that the value can be
> > > converted to what you want, and return an error if it can't. For example,
> > > you might use Integer.parseInt() to ensure that a valid integer was
> > entered.
> >
> >If the validate() method does the type checking then we must implement
> >type
> >conversion code and type checking code in every single form bean we
> >write!
> >On large systems, this is sometimes very unfun.
> >
> >Any thoughts?
> >
> >Regards,
> >Nick
> >
> >
> >
> > >
> > > --
> > > Martin Cooper
> > > Tumbleweed Communications

Re: Validating bean properties (WAS: Re: Stupd question aboutStruts and EJB.)

[Spencer Smith <sp...@newdestiny.net>]

Help!

Question:

Is there a simple way to set an index for an error message so that I can
vary it's placement on my JSP Page?

// In Action

// old code
errors.add(ActionErrors.GLOBAL_ERROR, new
ActionError("caremanager.mp.error.phoneFormat"));

// new code (preferredDayPhone is my field name)
errors.add("preferredDayPhone", new
ActionError("caremanager.mp.error.phoneFormat"));

// In JSP

<font color="#ff0000"><eCMS:preferredDayPhone.errors/></font>  ???




----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Cc: <st...@jakarta.apache.org>
Sent: Wednesday, February 28, 2001 8:06 PM
Subject: Re: Validating bean properties (WAS: Re: Stupd question aboutStruts
and EJB.)


> Nick Pellow wrote:
>
> >
> > I was considering an approach where coders wrote validation code in Java
> > (we all know java!)
> > yet the Struts framework executed it. You would extend or implement a
> > common java class/interface defining a single method,
> > public ValidationErrors validate();  say.
> > That is then mapped to the form field in an xml file somewhere.
> >
> > Struts, however could ship all the standard validations (such as Strings
> > to ints)
> > together.
> >
> > It is something I have not given much thought to yet, but would be
> > interested in
> > exploring further.
> >
>
> Beyond the thinking expressed so far on this thread, I've had two
additional ideas
> for functionality that should be included here:
>
> * Optional generation of client-side JavaScript code to do the kinds
>   of validations that make sense (required fields, number formats, etc.)
>   closer to the user.
>
> * The JavaBeans spec includes the concept of a PropertyEditor, which
>   lets you define a custom conversion between String and a bean data type.
>   JSP 1.2 supports this when doing attribute conversions -- we should look
>   at whether it can help us in the conversion/validation arena as well.
>
> Craig McClanahan
>
>
>

Re: Hook to bootstrap in Tomcat

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

Qiqi Dong wrote:

> Does anyone know how to bootstrap my own classes when start Tomcat. Does
> Tomcat actually provide a hook for that?

Qiqi, the best place to ask this is on the TOMCAT-USER list, rather than the
two lists you selected.

However, to save the trouble of re-asking, the answer varies by Tomcat
version:

* In Tomcat 3.x (based on servlet 2.2), about the only way
  to bootstrap your own classes is to create an initialization
  servlet, and mark it <load-on-startup>.  Then, in the init()
  method of this servlet, instantitate and configure your user
  objects as needed.

* In Tomcat 4.0 (based on servlet 2.3), you can do the above.
  Or, you can use the new "application event listeners" model
  to create an object that is notified when your webapp is started
  (and shut down), and can perform appropriate initialization
  for you.

Craig McClanahan

Hook to bootstrap in Tomcat

[Qiqi Dong <qd...@swbell.net>]

Does anyone know how to bootstrap my own classes when start Tomcat. Does
Tomcat actually provide a hook for that?

Hook to bootstrap in Tomcat

[Qiqi Dong <qd...@swbell.net>]

Does anyone know how to bootstrap my own classes when start Tomcat. Does
Tomcat actually provide a hook for that?

Re: Validating bean properties (WAS: Re: Stupd question aboutStruts and EJB.)

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

Nick Pellow wrote:

>
> I was considering an approach where coders wrote validation code in Java
> (we all know java!)
> yet the Struts framework executed it. You would extend or implement a
> common java class/interface defining a single method,
> public ValidationErrors validate();  say.
> That is then mapped to the form field in an xml file somewhere.
>
> Struts, however could ship all the standard validations (such as Strings
> to ints)
> together.
>
> It is something I have not given much thought to yet, but would be
> interested in
> exploring further.
>

Beyond the thinking expressed so far on this thread, I've had two additional ideas
for functionality that should be included here:

* Optional generation of client-side JavaScript code to do the kinds
  of validations that make sense (required fields, number formats, etc.)
  closer to the user.

* The JavaBeans spec includes the concept of a PropertyEditor, which
  lets you define a custom conversion between String and a bean data type.
  JSP 1.2 supports this when doing attribute conversions -- we should look
  at whether it can help us in the conversion/validation arena as well.

Craig McClanahan

Re: Validating bean properties (WAS: Re: Stupd question aboutStruts and EJB.)

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

Nick Pellow wrote:

>
> I was considering an approach where coders wrote validation code in Java
> (we all know java!)
> yet the Struts framework executed it. You would extend or implement a
> common java class/interface defining a single method,
> public ValidationErrors validate();  say.
> That is then mapped to the form field in an xml file somewhere.
>
> Struts, however could ship all the standard validations (such as Strings
> to ints)
> together.
>
> It is something I have not given much thought to yet, but would be
> interested in
> exploring further.
>

Beyond the thinking expressed so far on this thread, I've had two additional ideas
for functionality that should be included here:

* Optional generation of client-side JavaScript code to do the kinds
  of validations that make sense (required fields, number formats, etc.)
  closer to the user.

* The JavaBeans spec includes the concept of a PropertyEditor, which
  lets you define a custom conversion between String and a bean data type.
  JSP 1.2 supports this when doing attribute conversions -- we should look
  at whether it can help us in the conversion/validation arena as well.

Craig McClanahan