struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Gainty" <mgai...@hotmail.com>
Subject Re: Two Struts validation problems
Date Sun, 04 Mar 2007 00:59:57 GMT
concerning the initialisation of those beans which mechanism would take control for bean initialisation
when other bean initialisers are configured
(Im thinking of hibernate bean child set and or spring bean property)?

Thanks,
M-
--------------------------------------------------------------------------- 
This e-mail message (including attachments, if any) is intended for the use of the individual
or entity to which it is addressed and may contain information that is privileged, proprietary
, confidential and exempt from disclosure. If you are not the intended recipient, you are
notified that any dissemination, distribution or copying of this communication is strictly
prohibited.
--------------------------------------------------------------------------- 
Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant)
s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé
ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il
est strictement interdit de le diffuser, de le distribuer ou de le reproduire.
----- Original Message ----- 
From: "Ed Griebel" <edgriebel@gmail.com>
To: "Struts Users Mailing List" <user@struts.apache.org>
Sent: Saturday, March 03, 2007 6:50 PM
Subject: Re: Two Struts validation problems


> 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 <chris@christopherschultz.net> 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: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
>
Mime
View raw message