15
Vote

GetClientValidationRules() needs the container passed in

description

Please modify "ValidationExtensions.ApplyFieldValidationMetadata" so that "htmlHelper.ViewData.Model" gets passed into "v.GetClientValidationRules". The footprint for "GetClientValidationRules" will need to be modified to include "object container". This will make "GetClientValidationRules" consistent with its sister method "Validate(object container)". The container is often necessary for determining how to validate. I downloaded the source to verify that this is a small and workable change.

I've attached a project that demonstrates the problem and the ugly hack required to work around it. Look in Models\Request.cs. Essentially I had to make a provider, override CreateMetadata, and add the last container created into the AdditionalValues collection. This is related to bug #5117. I should not have had to do anything with DataAnnotationsModelMetadata to make this work.

file attachments

comments

BradWilson wrote Jan 8, 2010 at 12:04 AM

You shouldn't need the actual container object. The container type, already available from ModelMetadata, should be enough to do what you want to do.

brantheman wrote Jan 8, 2010 at 7:10 PM

I'm using a property on an object to determine whether or not to require a field. This is a set-at-runtime property, not the attributes on that property. The container type and metadata are insufficient.

brantheman wrote Jan 25, 2010 at 6:00 PM

There is a forum post dealing with this issue: http://forums.asp.net/p/1509269/3639276.aspx

I also attached a zip with the painful workaround.

FSleeper wrote Nov 14, 2012 at 5:01 PM

What is the preferred and valid approach for this, I've still not seen this addressed.

Just to recap, it would be preferrable for the TypeDescriptor to return the "Rules Engine" list of Attributes, which are simple attributes that support Client and Server Side Validations. This would resolve the GetClientValidationRules() returning the list of attributes based on the model DATA, not just the model TYPE that the existing works off.

(i.e. have a config database / engine that determines at RUN TIME what attributes should exist and return those only. This leverages existing architecture beautifully, meaning we don't have to hack the Annotations Provider CreateMetadata(), don't need to muck with adding the model itself to the metadata via one hack or another, don't need to Custom Model Validation Provider to "shove in" attributes, etc. etc.

Sign in to add a comment or to set email notifications