Yes, type casting a number string to integer will indeed throw away its decimal part if it has it. That's why it's a good idea to force the user to only enter integer numbers in the field. If you still receive a string with anything but integer numbers (because someone sent values not from your form), then you're still safe, because you're type casting the value.
Anyway, I agree it would be easier if the validator had a way to do it itself. I thought about that too. I think it could check the string contents with a regex and, in case it's valid, type cast the value itself, so you receive the proper value with the correct type, and proper errors in any other case. I'd like to know what dev's think about this topic too. Maybe there's a valid reason for validators to work whis way. Can you post your case in dev's group? On Tue, Mar 1, 2011 at 1:01 AM, oscar balladares <[email protected]>wrote: > Hi Gustavo. > > Thanks for responding [?] > > I had thought about Javascript validation, but what itches my head is why a > validator (almost tied in all user cases to the Form component) wouldn't do > what it is expected to do. > > I try to cast the input value, but when I cast something like this happens: > 4==(int)"4.1" > > So the cast will throw away the decimal part. And a value like "4.1" (which > is always string as it is submited from the form) > won't trigger the validation rules [?] > > Another thing I did was to cast the value to float, but when it is casted > It is indeed a Float not an Integer, so the validator will always > reject it even if it is a 666 > > That behavior itches my head!!! > > I will have to follow your advice, I will create something like isIntValue( > ) on my entity, and bind a AssertTrue validation rule to it. > So I will end throwing away major AssertType constraints like: int, > integer, double, float, decimal. > > Thanks again!! > > > 2011/2/28 Gustavo Adrian <[email protected]> > > In this particular case I do a type casting before binding the data to the >> object's property. So: >> >> $value = ( int ) $dataFromPost; >> >> $object->setIntegerValue( $value ); >> >> And then I force the user to type integer values on the form field via >> javascript. If he/she sends a value that's not an integer anyway, the worst >> case scenario would be that the integer value ends being a 0, which could be >> acceptable or not depending on your use case (I think is almost always >> acceptable). If you really need a different approach, then you could >> implement your own validator. >> >> Having said that, maybe these type validators could validate the coming >> string with a regex, and then, if it's valid, type cast to the according >> type? What do you think? >> >> >> >> Regards. >> >> On Mon, Feb 28, 2011 at 9:13 PM, oscar balladares >> <[email protected]>wrote: >> >>> Hi everybody. >>> >>> I have an entity which is validated via validation.yml file. >>> >>> Here is an extract of it: >>> >>> Sensio\HelloBundle\Entity\Person: >>> properties: >>> phone: >>> AssertType: integer >>> >>> >>> But this is tricky, because when I submit the form, the AssertType throws >>> me a validation error even if I typed >>> something like 12345 in the phone field. >>> >>> According to the api, Asserts like "int", "integer", "decimal", uses the >>> is_int() PHP function, so I read the PHP docs (on the official site) for >>> is_int(), is_integer() >>> and they say those function won't validate if the passed value comes from >>> a Form Input ($_POST[]) cause its type will be always a String. >>> They suggest (on PHP docs) to use the function is_numeric(). >>> >>> From there, I tried this on Symfony 2: >>> >>> AssertType: numeric >>> >>> And it worked perfectly, but it will accept decimal like 123.456 >>> And of course I want to validate an Integer not a float. >>> >>> >>> How can I validate this field? >>> Thanks! >>> >>> -- >>> If you want to report a vulnerability issue on symfony, please send it to >>> security at symfony-project.com >>> >>> You received this message because you are subscribed to the Google >>> Groups "symfony users" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/symfony-users?hl=en >>> >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony users" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/symfony-users?hl=en >> > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
<<349.gif>>
<<364.gif>>
