Jan 1, 2014 at 2:04 PM
Should the RelativeDateTimeValidator/Extended to accept a date rather than using DateTime.Now as the base for the validation; there are times when developer require a comparison with dates other than DateTime.Now; sometimes a fixed date other times a variable base on another property.

While I understand developers can implement their own validation attributes; it seem that these would standard and be helpful if the VAB had an implementation to support the above.

Please let me know your thoughts; I'm willing to submit an implementation as an example if this would assist.
Jan 8, 2014 at 4:48 AM
Thanks for the suggestion.

The intent of the RelativeDateTimeValidator is specifically to provide a means for validating a date relative to the current DateTime.

To validate against a static/constant DateTime you can use the DateTimeRangeValidator. To validate one date against another then there is the PropertyComparisonValidator. If you need to mix and match relative dates, constant dates, and date properties then you could achieve that by using XML configuration and changing the configuration as required. Or another way would be to define multiple rulesets and then apply the appropriate ruleset for the desired validation.

That said, Enterprise Library is open to community contributions. If you are interested then you can check the Issue Log to see the issue list and/or submit a feature request/bug report.

Randy Levy
Enterprise Library support engineer
Support How-to
Jan 9, 2014 at 3:26 PM
Thanks for reply, with regards to using the xml rules I was more thinking of a runtime dynamic validation.

For example a user specifies a starting date and the end date is automatically constrained by the attribute to be within 28days of the start.

Sent from my Windows Phone

Jan 11, 2014 at 3:18 AM
OK, I think I understand the scenario.

Currently you could achieve the above with a new calculated Property (EndDate - StartDate) and a RangeValidator but I do realize this adds properties just to support validation. If the 28 days was also dynamic you could add another property and change the range validator to a PropertyComparisonValidator.

So I think you would be looking for a RelativePropertyDateTimeValidator and it might look something like:
      0, DateTimeUnit.Day, RangeBoundaryType.Ignore,
    28, DateTimeUnit.Day, RangeBoundaryType.Inclusive, 
    ComparisonDateProperty = "EndDate")]
public DateTime StartDate { get; set; }

public DateTime EndDate { get; set; }

From a design and ease of use perspective, I like the idea of keeping each validator as simple as possible.

Randy Levy
Enterprise Library support engineer
Support How-to
Jan 11, 2014 at 12:02 PM
Yeah, that's exactly the user case, and its been a common user case I'm come across in a number of projects.

Sent from my Windows Phone