I recently had an issue with date validation in WPF using the Csla 3.8.2 framework. I have a date property that is exposed as a string publicly but has a SmartDate backing field. This seems to be the most common way to expose dates for UI purposes. The only problem is if the user types letters into the textbox, the SmartDate throws an exception and doesn't give a chance to be broken by a business rule.
I would like the user experience to be like so: The user is prompted to enter a date however the date is not required. If the user types in something that is invalid and can't be parsed to a date, I would like a business rule to break and a property status validation message to show.
There are a few dirty workarounds I have thought of so far like exposing the date as a separate public string variable with a string backing field or using a converter to parse out a datetime in ConvertBack and create a separate datetime validator for a textbox. I don't like either of these solutions.
Has anyone else solved this problem in a more elegant way?
That sounds like you have a private backing field of type SmartDate with a Property of type String. How about trying this:
public static PropertyInfo<SmartDate> DateModifiedProperty = RegisterProperty(new PropertyInfo<SmartDate>("DateModified", "Modification Date", new SmartDate(SmartDate.EmptyValue.MinDate)));
public SmartDate DateModified
{
get { return GetProperty(DateModifiedProperty); }
}
public string DateModifiedString
{
get { return GetPropertyConvert<SmartDate, string>(DateModifiedProperty); }
set { SetPropertyConvert(DateModifiedProperty, value); }
}
Jav
That would have the same issue as the original SmartDate backing field with a public string using the SetPropertyConvert.
The problem is that we bind to the string property so in the WPF in your scenario we would bind a textbox to the DateModifiedString.
As soon as the user types "abc" and tabs off the textbox, the DateModifiedString setter would get called and value "abc" would try to be parsed by the SmartDate object and the exception would be thrown.
A variation on your suggestion and what seems to work (but very dirty) is to have a public csla style string like DateModifiedString but with a string backing field. We would then add a business rule that would validate the string to make sure it is a date. If the string validates then the SmartDate backing field for the "real" property would be set. You basically have to manually synchronize both properties depending on which property is being set. I really don't like this solution.
I think if you need to handle this case, you just use string for your type. Then have a validation rule which passes if the string parses as a date, and fails otherwise. Then when you store or retreive the value, you do your conversion there.
Copyright (c) Marimer LLC