Re: Are rules mutually exclusive?

[Bob Silverberg]

Thanks Tony. I was confused by the first email because the behaviour
you were seeking is already in place. I see now that it was because of
the space.

Adding trim() will address that issue, as long as we're happy with
that definition. Do people think that a property/field that contains
only spaces should be considered empty?

Thanks,
Bob

On Sat, Apr 7, 2012 at 10:49 AM, Tony Garcia <tny...@gmail.com> wrote:
> hey Bob,
> Disregard that last email. I figured out that, for some reason because
> of a datepicker plugin I was using on the form field, there was always
> at least one empty space in the field when the form was submitted, so
> when the propertyHasValue() method was called in the Validation
> Object, the len(val) gt 0 check returned "true" even though no value
> was submitted. So I sent a pull request where I added a trim() to
> account for any blank spaces that were submitted.
>
> thanks,
> Tony
>
> On Mar 4 2010, 12:21 pm, Bob Silverberg <bob.silverb...@gmail.com>
> wrote:
>> Rules are not mutually exclusive at all. In fact the opposite it true.  Each
>> and every rule you add to a property will be enforced for that property. Of
>> course you can use contexts to have different rules apply in different use
>> cases, and you can create conditions as well, which will cause rules to only
>> be applied when conditions are met.
>>
>> Getting to your specific examples, whether a particular rule type also
>> implies a "required" rule is based entirely on how the rule is coded.  For
>> your example of rangelength, the code for the ServerRuleValidator looks like
>> this:
>>
>> <cfset var Parameters = arguments.valObject.getParameters() />
>>
>> <cfset var theLength =  Len(arguments.valObject.getObjectValue()) />
>>
>> <cfif theLength LT Parameters.MinLength OR theLength GT Parameters.MaxLength
>>
>>
>>
>> <cfset fail(arguments.valObject,"The #arguments.valObject.getPropertyDesc()#
>> must be between #Parameters.MinLength# and #Parameters.MaxLength# characters
>> long.") />
>>
>> </cfif>
>>
>> What's happening there is that the length of the contents of the property is
>> being determined, using Len(arguments.valObject.getObjectValue()) and then
>> that length is being tested against the MinLength and MaxLength parameters.
>> A length of 0 will naturally be less than the MinLength parameter, so the
>> validation would fail if the property hadn't been populated. So that would
>> mean that the rule would *imply *a required rule as well.
>>
>> Does that make sense?  If you wanted to have a rangelength rule that was
>> only applied if the property was actually populated (i.e., the password must
>> be between 6 and 12 characters long, if a password has been provided), you
>> could do that in a couple of ways:
>>
>> 1. Create a new validation type (e.g., optionalrangelength) by creating a
>> new ServerRuleValidator that includes logic to ignore properties with a
>> length of 0, and then specify that validation type for your rule.
>> 2. Use a condition on the rule.  I've never tried this specific use case,
>> but I would think that specifying:
>>
>> <property name="password" desc="Password">
>>        <rule type="rangelength" contexts="*">
>>                <param DependentPropertyName="password" />
>>                <param minlength="6" />
>>                <param maxlength="12" />
>>        </rule>
>> </property>
>>
>> would give the desired result, which would be that the rangelength rule
>> would only be applied if the password field had been populated.
>>
>> I suppose one final option, from a framework enhancement perspective, would
>> be to include an additional parameter which could be specified for the rule
>> to tell the framework to only apply the rule to a non-empty property. That
>> would basically be the same as the example I just gave above, but the syntax
>> would be clearer as I can see using <param DependentPropertyName="password"
>> /> as being a bit confusing to some.
>>
>> I'm going to start a separate thread to discuss the possibility of adding
>> that option to the rules.
>>
>> Thanks for raising the issue and let me know if you have any questions on
>> what I've written above.
>>
>> Cheers,
>> Bob
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Mar 3, 2010 at 6:43 PM, Thomas <awa...@gmail.com> wrote:
>> > If I have the following rule (case 1)....
>>
>> > <property name="password" desc="Password">
>> >        <rule type="required" contexts="*" />
>> >        <rule type="rangelength" contexts="*">
>> >                <param minlength="6" />
>> >                <param maxlength="12" />
>> >        </rule>
>> > </property>
>>
>> > versus this rule (case 2)...
>>
>> > <property name="password" desc="Password">
>> >        <rule type="rangelength" contexts="*">
>> >                <param minlength="6" />
>> >                <param maxlength="12" />
>> >        </rule>
>> > </property>
>>
>> > I remember you saying the rules were mutually exclusive, which would
>> > imply that the additional 'required' rule in case 1 would not be
>> > necessary, but perhaps I misunderstood.
>>
>> > In other words, does that mean that in case 2 the Password field is
>> > not required? But, if someone does populate the Password field, that
>> > it has to be between 6 and 12 characters?
>>
>> > Thanks,
>> > Thomas
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "ValidateThis" group.
>> > To post to this group, send email to valida...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > validatethis...@googlegroups.com<validatethis%2Bunsubscribe@google groups.com>
>> > .
>> > For more options, visit this group at
>> >http://groups.google.com/group/validatethis?hl=en.
>>
>> --
>> Bob Silverbergwww.silverwareconsulting.com
>>
>> Hands-on ColdFusion ORM Training @ cf.Objective() 2010www.ColdFusionOrmTraining.com

--
Bob Silverberg
www.silverwareconsulting.com

[John Whish]

Can I just clarify, that you're not proposing to trim the value, just check that the value contains any other printable character other than a space?

My only concern would be that if you wanted to allow a space, then you wouldn't be able to get around it (other than replacing it with some other character). Whereas, with it as is, you can choose to trim the values before or when you populate the object.

John

Bob Silverberg
www.silverwareconsulting.com

--
You received this message because you are subscribed to the Google Groups "ValidateThis-dev" group.
To post to this group, send email to validate...@googlegroups.com.
To unsubscribe from this group, send email to validatethis-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/validatethis-dev?hl=en.

[Matt Quackenbush]

+1. I think that it is more appropriate to do the trimming on populate(). I do not believe that should be the responsibility of the validation framework/service.

[Sumit Verma]

I agree, trim should be done on populate() if needed. Because if a space was passed then that is a value which is validated based on rule. In case of Date you won't be able to save it to DB as space anyways because your DB will throw error.

Sumit Verma
Partner / Vice President | ten24, LLC
office: 877.886.5806 x 103 | mobile: 617.290.8214
www.ten24web.com | www.linkedin.com/in/sverma | twitter: blogonria