Dear Ed:
Thanks so much for your response (all other that replied -- thanks so
much as well!).
For now, I would like to stick to the first solution: ActionForm with
String properties.
I already have VOs and don't mind copying over from the form to the VO
and back.
My last question on this issue is: if I use BeanUtils.copyProperties(vo,
form) where
I have a form.field : String and vo.field : int (same name, different
type) and have
validated the form so that I know form.field is convertible to an int,
would copyProperties()
do that for me? Is that what I should be using (and not
PropertyUtils.copyProperties())?
Thanks so much,
oren
Ed Griebel wrote:
Chris is right, the zero occurs in the java.lang.Integer(String)
constructor when it is passed a non-numeric string value. You would
see this happen in your ActionForm and action class if you weren't
using the validator. The same thing happens with a non-numeric in a
java.lang.Double(String) constructor.
For Struts 1.x, the question of Strings vs. native types in formbeans
comes up about every 6 months, judging from the questions this week it
seems it's that time again. The general consensus is that Strings
preserve incorrect input for redisplay and don't do "mysterious"
conversions like above, but if native types are used then the formbean
can also be used as a data transfer object for the database layer,
removing a set of DTO (a.k.a. DO, VO, etc) classes. Of course, using
LazyDynaBeans and their ilk let you have the best of both worlds :-)
-ed
On 3/3/07, Christopher Schultz <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Oren,
Oren Livne wrote:
> Dear Chris:
> Yes, other validations are working. For instance, I also have an
> "intRange" validation on the same integer field. If I type a letter
for
> the integer field, it sets it to 0, displays it as 0, and says it's
> outside the permissible range (which happens to be 1-4). No errors on
> startup. Any idea what could go wrong? :(
>
> Should I use a String instead of int in my form for that field?
I pretty much always use strings.
If you have your field type set to "java.lang.Integer", then its value
will be either null of an actual number. It's possible that the
converter used by the validator will set an invalid input to new
Integer(0) just as a default value. So, for instance, if you enter "foo"
in for a number, it comes back "0", when it should have been "foo" (at
least, I would expect it to say "foo" and an error message).
IMHO, a rejected form should come back to the user in exactly the same
way it was submitted (plus error messages, of course).
Using strings for all form fields /will/ work, but I'm not entirely sure
it's necessary to make that happen. I just know that it works for me.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF6c0b9CaO5/Lv0PARAt6qAJ49qun09ehwDYu0lpva3Cvyy0c7EACglUF2
fLHeh3/nKs3iQ2sgPG5XBXA=
=jdT/
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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]
--
======================================================================
Oren Livne, Ph.D.
Research Assistant Professor of Mathematics
RUReady Software Architect
Academic Outreach and Continuing Education
1901 East South Campus Dr., Room 2197-D
University of Utah, Salt Lake City, UT 84112-9399
Tel : (801) 581-6831 Cell: (801) 631-3885 Fax: (801) 585-5414
Email: [EMAIL PROTECTED] Web: http://ruready.net/oren
======================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
