Conditional Validation in ASP.NET MVC – RangeIf


Simon Ince made a great post about conditional validation in mvc which he extended in his post conditional validation in mvc 3. mvc validation is one of mvc’s great extensible points . The framework comes with a decent amount of validations attribute such as range, stringlength etc but sometimes we find ourselves wanting to perform a specify type of validation that the framework doesn’t support and conditional validation is a perfectly good example. This is one of those validation types that most people feel the mvc team should have included in the framework but hey, they cannot do it all,¬† so we look to ourselves and to good people like Simon to the rescue.

Simon goes into details on how to create a RequiredIf validation so I wont elaborate on that (just dive into the links above for info on RequiredIf validation). In using Simon Requiredif validation, I decided its would be great to build on it to be applicable to other rules like Rangeif, StringLenghtIf, etc, starting with RangeIf. The first thing I needed to do was define the signature of the validation attribute. To keep things consistent with Simon’s, I decided to go with the signature as follows for an age property on the person class-

[RangeIf(11, 25, "IsUKResident", false, ErrorMessage = "If you are not a UK  resident, your age has to be between 11 and 25")]

The next thing to do was to define the RangIf attribute class below , inheriting from RangAttribute
public class RangeIfAttribute : RangeAttribute , IClientValidatable
public string DependentProperty { get; set; }
public object TargetValue { get; set; }

public RangeIfAttribute(int minimum, int maximum, string dependentProperty

, object targetValue): base(minimum, maximum)
this.DependentProperty = dependentProperty;
this.TargetValue = targetValue;

protected override ValidationResult IsValid(object value,

ValidationContext validationContext)
// get a reference to the property this validation depends upon
var containerType = validationContext.ObjectInstance.GetType();
var field = containerType.GetProperty(this.DependentProperty);

if (field != null)
// get the value of the dependent property
var dependentvalue = field.GetValue(validationContext.ObjectInstance, null);

// compare the value against the target value
if ((dependentvalue == null && this.TargetValue == null) ||
(dependentvalue != null && dependentvalue.Equals(this.TargetValue)))
// match => means we should try validating this field
if (!base.IsValid(value))
// validation failed - return an error
return new ValidationResult(this.ErrorMessage, new[]

{ validationContext.MemberName });

return ValidationResult.Success;

public IEnumerable<ModelClientValidationRule> GetClientValidationRules

(ModelMetadata metadata, ControllerContext context)
var rule = new ModelClientValidationRule()
ErrorMessage = FormatErrorMessage(metadata.GetDisplayName()),
ValidationType = "propertydependencyrule",

string depProp = BuildDependentPropertyId(metadata, context as ViewContext);
string targetValue = (this.TargetValue ?? "").ToString();
if (this.TargetValue.GetType() == typeof(bool))
targetValue = targetValue.ToLower();


rule.ValidationParameters.Add("dependentproperty", depProp);
rule.ValidationParameters.Add("targetvalue", targetValue);
rule.ValidationParameters.Add("rule", "range");

yield return rule;


private string BuildDependentPropertyId(ModelMetadata metadata,

ViewContext viewContext)
// build the ID of the property
string depProp = viewContext.ViewData.TemplateInfo.GetFullHtmlFieldId

// unfortunately this will have the name of the current field appended to the beginning,
// because the TemplateInfo's context has had this fieldname appended to it. Instead, we
// want to get the context as though it was one level higher (i.e. outside the current property,
// which is the containing object (our Person), and hence the same level as the dependent property.
var thisField = metadata.PropertyName + "_";
if (depProp.StartsWith(thisField))
// strip it off again
depProp = depProp.Substring(thisField.Length);
return depProp;

The code above is self explanatory so I wont elaborate. Note that we pass on the client rule and its parameters through rule.ValidationParameters in the GetClientValidationRules method. The next thing to do was create my client script (unobtrusive adapter) below
function (value, element, parameters) {
var id = '#' + parameters['dependentproperty'];

// get the target value (as a string,
// as that's what actual value will be)
var targetvalue = parameters['targetvalue'];
targetvalue =
(targetvalue == null ? '' : targetvalue).toString();

// get the actual value of the target control
// note - this probably needs to cater for more
// control types, e.g. radios
var control = $(id);
var controltype = control.attr('type');
var actualvalue = "";

case 'checkbox' :
actualvalue = control.attr('checked').toString(); break;
case 'select' :
actualvalue = $('option:selected',control).text(); break;
actualvalue = control.val(); break;

// if the condition is true, reuse the existing
// required field validator functionality
var rule = parameters['rule']
var ruleparam = parameters['ruleparam']
if (targetvalue === actualvalue)
return $.validator.methods[rule].call(
this, value, element, ruleparam);

return true;

['dependentproperty', 'targetvalue', 'rule', 'ruleparam'],
function (options) {


options.rules['propertydependencyrule'] = {
dependentproperty: options.params['dependentproperty'],
targetvalue: options.params['targetvalue'],
rule: options.params['rule'],
ruleparam: eval(options.params['ruleparam']),
options.messages['propertydependencyrule'] = options.message;

That’s it. We now have our RangeIf validation attribute. Notice I modified Simon’s client side code to a generic propertydependencyrule so you can use propertydependencyrule for other propertydependency validation attributes like StringLenghtIf by passing along the max jquery.validator¬† rule and its parameters. In my next post, I will extend this to RegularExpressionIf, StringLenghtIf, and more. Stay tuned.

A reminder of why I dislike webforms


A few hours ago, I stumbled on mvp –¬†an up and coming opensource framework¬†who’s aim¬†to¬†to unit the productivity of webforms¬† and the exensibilty of mvc. After combing through the links and the how-to’s on , I had warmed up to the idea and was willing to give it a try in the new furture. This post should probably be titled mvp but¬†the blog post(¬†in relation to mvp in¬†support of webforms got my heart going so I decided to respond with this post. If you have head it all, please skip this post else you are welcome to read on.

The blog post( in support of webforms list some very interesting point that I strongly support especially in relation to viewstate. People who complain about veiwstate just don’t know how to use it and its a fact. I actually agree with everything except for his argument¬†quoted below¬†in support of webform controls.

Controls are great, they package up some functionality and make it easy to redistribute. But people often say that this is one of the big downsides of WebForms and MVC gives you much better flexibility. But think about some of the trivial (read: boring) tasks which we have to do as developers:

  • Create a login form
  • Output a collection of data using a template

So with MVC this is something that you end up having to write yourself, sure there are some helpers like Html.EditorFor and stuff so you can quickly display something. And it’s true there’s plenty of good extensions to do things like Repeaters, so this is just taking WebForms concept into MVC right?

One of the other main criticisms of controls is that they generate HTML for you that is hard to style, and often unchangable. But think about what they are trying to generate, a standard design cross-browser. Try having a floating layout which can be dropped anywhere and look the same?

True it makes them less flexible, but it depends what you’re trying to achieve

Sure, controls are great because they allow us to componentize and reuse functionalities but¬†with a greater sacrifice. If you just want to get up and going looking like ooh say anything else but precise, webform controls will do it well. Webforms are great in its composition architecture and since its been around for a while (.net world), its proven itself with a ton of best practices and guidlines. On the other hand, I(I spoke for myself and only myself)¬†dislike it because it tends to create what i call “robot developers”. Run an http test against a decent webform dev and you will actual find out what he knows about the underlying technology. Sure, they dont “need” to know it because they just have to drag and drop control but… you(assuming you agree)¬†and i know that in order to build great application, you almost have to go beyond drag&drop and property setting. Another issues I have with webforms is¬†the inability to¬†control the html rended by the controls.¬†The author asserts that its hard to¬†stay compliant¬†with the statement- “One of the other main criticisms of controls is that they generate HTML for you that is hard to style, and often unchangable. But think about what they are trying to generate, a standard design cross-browser. Try having a floating layout which can be dropped anywhere and look the same?”, but that’s only useful, again, to the “robot develper” because instead of learning how to do it using the right technology(thml,css,js), they end up relying on the control to do it. To add to injury, even though they are designed to generate standard cross-browser html ,they don’t. There are too many browsers to think your webform control will work flawlessly in everyone of them. In conclusion, controls in webforms hurts the framework to some extent. I will¬†advocate controles but only when the engineer has the ability to make modification when need be. That’s why I love mvc. It takes sometime to get up to speed and yes it has its own problem but in the end, I believe as a designer/developer, mvc¬† is more rewarding that webforms.¬† Hopefully, mvp will bring these two together.


Credits: Post image by ksomero at

Timestamp issue with MySql connector 6.0 – 6.1 for Entity Framework


This is really a short post as to highlight an issue that I run into (and most will) when using MySql with Entity Framework employing the mysql connector net.



I work mostly on my laptop which has mysql connector 6.0.4 installed. Using the connector in conjunction with EF v1 generated my domain object with timestamp fields mapping from a binary in my conceptual schema to timestamp in my physical schema.  Everything worked just fine till I deployed to my production machine and realized I didn’t have mysql connector installed on my production server. So…I did what most will do, download the connect but installed the latest version (v6.1). After deploying my app to the server, the unexpected happened. My app was broken. The error message indicated that Edm.binary was not compatible to mysql.timestamp. OK, I was stumped. The app works just fine on my my laptop why not on my server.



After a couple of hours using process of elimination, I realized that using version 6.1 of the connector sets your mapping for timestamp from Edm.DateTimeOffset(conceptual schema) to timestamp (physical schema)which worked fine but version 6.0.4 of the connector sets your mapping for timestamp from Edm.binary(conceptual schema) to timestamp (physical schema) which also works as well. DateTimeOffset is a type specific to Sql server so the best option for me was to stay with 6.0.1  (using binary) which is generic and can be used with other db’s if ever need.