No null strings allowed by "SetProperty<P>(PropertyInfo<P>, P, Security.NoAccessBehavior)"

No null strings allowed by "SetProperty<P>(PropertyInfo<P>, P, Security.NoAccessBehavior)"

Old forum URL: forums.lhotka.net/forums/t/8253.aspx


rxelizondo posted on Friday, January 01, 2010

Hi

I was looking at the:

SetProperty<P>(PropertyInfo<P> propertyInfo, P newValue, Security.NoAccessBehavior noAccess)

Method code just now and noticed the following chunk of code in there:

if (typeof(P) == typeof(string) && newValue == null)
newValue = Utilities.CoerceValue<P>(typeof(string), null, string.Empty);

Interesting I thought, so I decide to experiment and created a little example, here are the gist of the example:

------------------------------------------------------------------
private static PropertyInfo<string> XyzProperty = RegisterProperty<string>(c => c.Xyz, string.Empty, null);


public void DoIt()
{
SetProperty<string>(XyzProperty, null, NoAccessBehavior.ThrowException);
Console.WriteLine("Am I null??? " + (ReadProperty(XyzProperty) == null));
}

------------------------------------------------------------------

The console result will be: "Am I null??? False"

One would expect that having a string property with a default value of null would be able to accept a null string value but this does not appear to be the case. Turns out, that the end value of the property will be changed empty string.

Now I do realize that the CSLA descourages the user of null values for strings in favor of empty string but I though it was up to the user to decide.

Thanks.



tmg4340 replied on Friday, January 01, 2010

I think this was done because most UI controls don't do well with null-string property values.  (Most of them don't do well with any type of null-value property...)  It also brings up the question of whether a null string is different from an empty string.  I know that technically they are, but from a user experience I'm not sure - e.g. what's the difference between no description and an empty description?  I think it's a little different from something like a numeric field, where there potentially could be a difference between no value and a 0 value...

- Scott

RockfordLhotka replied on Friday, January 01, 2010

That is exactly correct. The helper methods in CSLA (like SetProperty()) eliminate null string values because they tend to cause data binding to fail. If CSLA didn't do this, 99% or more of all property getter/setter code would need additional code to remove the null values.

If you really need to reflect a null string as different from an empty string then you won't be able to use the helper methods. That's OK - everything the helper methods do for you, you can do yourself - SetProperty() just calls a bunch of protected methods in the end.

rxelizondo replied on Saturday, January 02, 2010

Well, I am obviously missing something very obvious here. The problem is that the behavior is exhibited by the SetProperty method, not the GetProperty method.

Why would the framework care at all about storing a null string as a string.Empty? The framework could easily store the string as null and don’t have any problems at all correct?

If we were to rewrite the example above and we only executed the:

Console.WriteLine("Am I null??? " + (ReadProperty(XyzProperty) == null));

The console result will be: "Am I null??? True”

Now that would be bad news for the UI since we are returning a null. Would it not make more sense to helper method to return a string.Empty when we are *reading* more than when we are *writing* to the framework? Or if anything, should we not be doing the conversion in both places?

And by the way, I don’t have a need to distinguish between null and an empty string, I was just bored and decided to peek inside the CSLA code just for fun and that is when I found this. I am simply curious.

Thanks.

Copyright (c) Marimer LLC