Are rules mutually exclusive?

34 views
Skip to first unread message

Thomas

unread,
Mar 3, 2010, 6:43:43 PM3/3/10
to ValidateThis
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

Bob Silverberg

unread,
Mar 4, 2010, 11:21:55 AM3/4/10
to valida...@googlegroups.com
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



--
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.
For more options, visit this group at http://groups.google.com/group/validatethis?hl=en.




--
Bob Silverberg
www.silverwareconsulting.com

Hands-on ColdFusion ORM Training @ cf.Objective() 2010
www.ColdFusionOrmTraining.com


Thomas

unread,
Mar 5, 2010, 12:07:21 PM3/5/10
to ValidateThis
Thanks Bob, that helped me. I initially had the impression that was
already there.

I vote for building it into the CF9/Hibernate version of
ValidateThis :)

Thomas


On Mar 4, 8:21 am, 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.

> > validatethis...@googlegroups.com<validatethis%2Bunsu...@googlegroups.com>

adam drew

unread,
Mar 5, 2010, 12:46:29 PM3/5/10
to valida...@googlegroups.com
@Thomas,

technically speaking the ValidateThis framework already supports CF9/Hibernate since it is orm/mvc agnostic.. so it doesn't really need a "version" for it.. only some extras :)



To unsubscribe from this group, send email to validatethis...@googlegroups.com.

Thomas

unread,
Mar 5, 2010, 4:21:14 PM3/5/10
to ValidateThis

oooh... nice... do I hear a sample app coming?


T

> > <validatethis%2Bunsu...@googlegroups.com<validatethis%252Buns...@googlegroups.com>

Bob Silverberg

unread,
Apr 7, 2012, 1:49:51 PM4/7/12
to Tony Garcia, ValidateThis, validate...@googlegroups.com
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.

>> > 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

Tony Garcia

unread,
Apr 8, 2012, 9:51:07 PM4/8/12
to ValidateThis
I honestly can't think of a use case for wanting to submit empty
spaces on purpose to be stored in the db. Although I guess another way
to look at it is that it's the developer's job to decide whether empty
spaces = empty field and do a trim() on the data BEFORE validation
takes place. Hmmm....

-Tony

Tony Garcia

unread,
Apr 8, 2012, 9:57:24 PM4/8/12
to ValidateThis
I can't find a use case for wanting to submit blank spaces to the db.
But I guess another way to look at it would be that the decision to
strip out blank spaces should be taken BEFORE any validation is done.
Hmmm....

-Tony

Tony Garcia

unread,
Apr 8, 2012, 10:41:57 PM4/8/12
to ValidateThis
Sorry for the duplicate message. Google groups was acting weird on me and I didn't know if the initial post went through.

-T

To unsubscribe from this group, send email to validatethis...@googlegroups.com.

Bob Silverberg

unread,
Apr 11, 2012, 9:18:37 PM4/11/12
to valida...@googlegroups.com
So I think the consensus is that VT should not change, and if you want
to treat spaces as empty then you should trim before validating.

Thanks everyone for your input,
Bob

On Sun, Apr 8, 2012 at 9:51 PM, Tony Garcia <tny...@gmail.com> wrote:

> To unsubscribe from this group, send email to validatethis...@googlegroups.com.

Reply all
Reply to author
Forward
0 new messages