Validation Messages Based on the property name

nermin posted on Saturday, June 03, 2006

Hello everybody,
My problem is a validation message like "EmailAddress required." (notice no space between Email and Address - it is an actual property name).  I was hoping to see past posts on  this issue, but have not found anything yet.

I would like to solve this by creating an Attribute like, for example ValidationNameAttribute that can be assigned to class properties and hold the "user  friendly" description of a property name.

Then the only way I see to implement this is by replacing common rules methods with one my own.  For example if you take a look at the StringRequiredRule, I would replace the line that states:

e.Description = e.PropertyName + " required";

with following lines:
ValidationNameAttribute valName = GetValidationNameAttr(target, e.PropertyName);
if(valName == null)
    e.Description = e.PropertyName + " required";
else
    e.Description = valName.PropertyName + " required";

Where GetValidationNameAttr() would be a method that uses a reflection to check whether specified property has ValidationNameAttribute assigned, and if it does passes back a reference to it.

The reason I am asking if this is correct approach is that this  looks like too common problem not to be solved by someone else, and therefore I would like to compare other approeches to mine, and also I do not want to reinvent the wheel if someone else has already implemented this.

I am also hoping that if Rocky happens to read this post, to hear his opinion, and if the solution could be "compatible" name wise and such with future direction of CSLA 2.0.x that would be even better.

Another idea that I would like to propose is if this web site could also hold a libraries of proposed extensions to the CSLA, and then we as user's could either contribute or vote, having the most popular ones being the most likely to be built in the future  versions of CSLA core.  I believe that is what NAnt community does with their extensions.

Thanks,

Nermin

Brian Criswell replied on Sunday, June 04, 2006

Why not use the resources instead?  You can use the property name to point to an entry in the resources file that contains the name of the property and use that instead.  Something like this could work:

ResourceManager.GetString(e.PropertyName + "Required", System.Globalization.CultureInfo.CurrentUICulture);

could return "Property Name required" and have the bonus of being localizable.  This could then default to e.PropertyName + " required" if it could not find the resource string.

Edit: The downside of this is that the rule definitions have to be in your assembly along with the resource strings.

I personally think it would be easier if everyone posts their modifications to CSLA as groups of files.  Otherwise we might have too many versions of assemblies running around.  Maybe this could be in a separate section of the forum to help keep them together.  Which reminds me, I need to post my updated FilterableListBase and SafeDataRowReader one of these days...

nermin replied on Sunday, June 04, 2006

Thanks Brian,

I really like your idea, especially because it takes localization into account.  Like you said the problem would be down the road if I want to create a shared library of Custom rules that would be moved into a separate assembly. 

I am sure we could account for that by creating a config file entry that designates in which assembly we should look for the resource strings besides the assembly where rules are defined.  Another solution is to always look for resource strings in two places:
1. main assembly
2. assembly that contains the rules

As far as the extensions to the CSLA,  I was thinking that any proposed solution would not delve into main CSLA source but rather define overrides in separate assemblies that could be shared amongst us.  Then the ideas from those libraries, if they are popular could be considered in future versions of CSLA, and merged back into the main assembly.  Just an idea, I am not sure whether this is feasible.

AaronEngel replied on Thursday, November 16, 2006

I am using the approach found under post http://forums.lhotka.net/forums/post/6566.aspx with success.

david.wendelken replied on Thursday, November 16, 2006

Take a look at PublicRuleInfo in the CslaSrd sub-project within the Csla Contrib project.

I've gotten good part of what you wnat working there, using a resources file.

I'm planning to add support for "property user-names" to the code over the next week.

RockfordLhotka replied on Friday, November 17, 2006

fwiw, this topic is on my to-do list for future versions of the framework, so the ability to pass a human-friendly property name would exist directly in RuleArgs.

RockfordLhotka replied on Friday, November 17, 2006

I'm also considering using the decorator pattern to create another standard variation on RuleArgs (or perhaps in RuleArgs itself) so it would be possible to pass arbitrary name/value pairs through to the rule method.

Right now the only way to pass extra data is to create subclasses of RuleArgs - which is elegant, but makes some common code-gen scenarios much harder than they could be. If RuleArgs has an associated dictionary for arbitrary values, it would be easier to pass simple parameter values in a standardized manner, without a code-gen tool needing to somehow know, or infer, the type of the args parameter coming into the rule method.