Correcting user input - where's the best place to do it?

tiago posted on Thursday, July 16, 2009

Hi,

Some users insist on leaving heavy folder on top of the space bar or just don't understand the concept "separate words with one space". Well sometimes they understand it but accidents happen all the time. Anyway the point is that sometimes we need to correct strings that the user typed:
- trimming extra spaces
- correcting word casing
- automatic spell checking

This need exists for several reasons namely because there is no point on having a unique field for names if users don't leave extra spaces all around.

This is not an UI issue as it is tyed to object validation. Some frameworks do it on the validation methods. As far as I can see, Csla uses validation only to check if everything is all right though I never saw an example of correcting user input. I can see no reason not to do it on validation rules, before all other rules are executed.

rsbaker0 replied on Thursday, July 16, 2009

You can change property values in validation rules -- I do it all the time.

Another place to do this is in the property setter.

Be aware that a quirk of WinForms binding may result in the binding not showing changes to a property made during the handling of the property changed notification. CSLA has a BindingSourceRefresh extender control you can use to work around this.

JoeFallon1 replied on Friday, July 17, 2009

FYI - Rocky has commented on this before - he regrets calling them "ValidationRules" - he would prefer to call them BusinessRules instead. For exactly the reason you stated - people only think they can do validation with them. But you can easily correct the input through the use of a rule - just return True in every case. The rule then runs automatically each time the property is changed - so you can capitalize the first letter, trim excess spaces, whatever.

Joe

PS - Rocky "can't" change the name to BusinessRules as that would be a major breaking change!

ajj3085 replied on Monday, July 20, 2009

Yes, a validation / business rule would be the way to go.

He could change it, after all that's what the Obsolete attribute is for... first set it to issue a warning, then maybe in the next major release a compiler error. And it'd be easy to fix... a simple global replace and you'd be good to go.

Already compiled code would be unaffected.