Dependencies?

[jonatha...@gmail.com]

Jeff,

I need to create a new rule that validates an user inputted date/time
is after a dynamic date/time based on the time of submission.

After looking through some of your validation rules I think I will
need to use dependencies to compare the form value to a dynamic
value. Do you have an example of this?

Thanks,
Jonathan

[Jeff Chastain]

Jonathan,

Dependencies typically come into play where the validation rules for one
field depend upon the value of another field in the same form. For example,
if user selects the value "other" from a drop down, they must provide a
value in the text box describing "other".

In your case, even though your date is dynamic, if it is dynamic based upon
the current time and some calculation, then it should not be a dependency.
You should be able to just create a custom validation rule which calculates
the dynamic date based upon Now() and then compares the user entered date
against the calculated date.

Does this make sense?

-- Jeff

Jeff Chastain
Senior Software Architect

Alagad, Inc.
www.alagad.com

[Jonathan Burnham]

Thanks Jeff,

That helps a lot.  I was over-thinking the task at hand.

In the example you gave about dependencies, what would the XML look like?

Thanks again,
--Jonathan

[Jeff Chastain]

Jonathan,

 

Here is any example where a form has two fields … bodyHTML and bodyText.  In this case, at least one of these fields were required.  So, a custom rule was written with the id “emailBody” that checked to make sure one field or the other had a value.  The XML definition then looked like this:

 

                <assert rule="emailBody">

                                <depend name="bodyHTML" value="bodyHTML" />

                                <depend name="bodyText" value="bodyText" />

                                <message name="invalid" value="public.common.emailMessage.body.error.required" />

                </assert>

 

Then, the corresponding validator looked like this:

 

                <cffunction name="validate" access="public" output="false" returntype="string"

                                hint="Check to see either the bodyHTML field, the bodyText field, or both contain a value.">

 

                                <cfargument name="data" type="any" required="true" hint="The data to be validated" />

                                <cfargument name="args" type="struct" required="false" default="#structNew()#" hint="The addtional arguments necessary to validate the data" />

                                <cfargument name="dependencies" type="struct" required="false" default="#structNew()#" hint="The additional dependencies necessary to validate the data" />

                               

                                <!--- check to see if either the bodyHTML or bodyText values contain data. --->

                                <cfif len( trim( arguments.dependencies.bodyHTML ) ) OR len( trim( arguments.dependencies.bodyText ) ) >

                                                <cfreturn true />

                                </cfif>

 

                                <cfreturn "invalid" />

                </cffunction> <!--- end: validate() --->

 

Hope that helps.

[Jonathan Burnham]

So, what field do you use for the 'name' attribute of the dataElement tag above the assertion?  Or, does it matter since whatever field you use will not be required anyway?

--Jonathan

[Jeff Chastain]

In the case I mentioned, the assertion was not contained within a data element.  Assertions may also be contained within data sets when they apply more globally as this one did.   In the previous case I described where an “other” text fields required state depends upon the value of a drop down select, that assertion would be nested inside the data element named for the text field with the dependency being the name/field for the drop down.

[Jonathan Burnham]

Thank you so much for the insight.  I think I have a handle on dependencies now.  Going back to my original question....  I think instead of hard coding now() + 24 hours into a new rule, I will pass the dynamic date to compare in a hidden field and make that a dependency on the validation of the user's date/time input.  This will make the new rule a little more reusable.

We love Validat!

Have a great weekend,
--Jonathan

[Jeff Chastain]

This is not related to validat, but beware of the security implications of using hidden form fields.  Anybody could capture the source of your form, alter the value of that hidden form field, and then submit potentially invalid data.  The FireBug plugin will allow you to do this very easily.

 

A better option might be to pass in your formula or a set of parameters to the validator object via its constructor.  This could be easily achieved using ColdSpring allowing you to pass in a certain number of hours for example to be added or removed from the current time and would not require hard coding that value into the validator, but would be significantly more secure than using a hidden form field.

[Jonathan Burnham]

Good point.  Until I am a little more comfortable with ColdSpring (and for the sake of speediness in completing this), if there any risk in appending the form structure on post?

--Jonathan

[Jeff Chastain]

Not sure I follow you.  Anything being sent via post or get is susceptible to hacking.  I would not base my validation rules off of anything the that had the potential to be changed or hacked in that manner …. that is the point of Validat, to check that the data being submitted is valid.  If your validation rules are being sent with that same data, there is little point in validating at all as it is all susceptible to hacking.

 

Maybe I just misunderstood.

[Jonathan Burnham]

I mean once the form has been submitted, on the server-side, before the form is passed to Validat, something like this...

form.NewFormField = DateAdd("d",1,now());

Then use NewFormField (which never existed on the client, and if it had is now overwritten) as a dependency in validating the user's date/time input.  This all happens on the server-side after the form is submitted.

--Jonathan

[Jeff Chastain]

No, once you are server side with the data, adding properties to the form scope is not a problem.  Best practice, probably not, but it will work.