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?
Senior Software Architect
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:
<depend name="bodyHTML" value="bodyHTML" />
<depend name="bodyText" value="bodyText" />
<message name="invalid" value="public.common.emailMessage.body.error.required" />
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 />
<cfreturn "invalid" />
</cffunction> <!--- end: validate() --->
Hope that helps.
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.
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.
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.
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.