Consistency within the Content API's

[James South]

Strings irk me.. They're awkward to maintain conventions with especially when publicly editable and they are unpleasant to deal with when calling API's.

And they cause bugs...

In the Umbraco CMS at present it possible to add two distinct properties with the following aliases to a single doctype.

propertyOne

and

pRoPeRtyOnE

When querying IPublishedContent using:

GetPropertyValue(this IPublishedContent content, string alias, bool recurse)

The alias is case insensitive which produces ambiguity. 

When using the Content API, those aliases are case sensitive. That's poor enforcement of convention/style.

IContentBase.SetValue(string propertyAlias, object value);

Personally I would abstract those property aliases away; the developer/user shouldn't have to care about them; make them invariant upper-case or hash them and that ambiguity is gone. Deep in the API you can have a single method that creates those hashes that can be called in turn from methods such as the one above.

With greater convention the second method could be rewritten as.

public static void SetValue<T>(this IContentBase contentBase, Expression<Func<T>> propertyLambda)
{
    MemberExpression expression = propertyLambda.Body as MemberExpression;

    if (expression == null)
    {
        throw new ArgumentException("You must pass a lambda of the form: '() => Class.Property' or '() => object.Property'");
    }

    PropertyInfo property = expression.Member as PropertyInfo;
    if (property != null)
    {
        MemberExpression member = (MemberExpression)expression.Expression;
        ConstantExpression constant = (ConstantExpression)member.Expression;
        object fieldInfoValue = ((FieldInfo)member.Member).GetValue(constant.Value);
        object value = property.GetValue(fieldInfoValue, null);
       
        // Use whatever hashing method we use.
        string name = property.Name.ToSafeAlias();

        // Call string,string method probably internal and hidden away.
        contentBase.SetValue(name, value.ToString());
    }
}

With a signature as follows.

IContent.SetValue(() => object.Property);

Lambda expressions are ubiquitous and I think it would be unfair to suggest that developers wouldn't understand the syntax. We use similar expressions in MVC for helpers anyway. Plus, all the difficult stuff like MemberExpressions are tucked away in core. 

Would it be feasible to change the API like this in V8? I'd love to help contribute.

[Shannon Deminick]

This is only possible when we start doing code generation for document type classes otherwise strongly typed doesn't exist. Strongly typed needs to be built on top of these non specific methods, not the other way around. It wouldnt be hard to update the current 'object' method to do the right conversions for currently "unsupported" types... That is really just an oversight for things like 'long' or throw meaningful exceptions when conversions can't take place.

The main thing is that property type aliases should never be case sensitive, if they are in that method then that is a bug, especially because that wouldnt work with the sql queries because those are case insensitive.

If there is a bug with property type aliases being case sensitive then we need to fix it which is probably just a case of accidentally using 'Equals' instead of 'InvariantEquals'

Having a generic strongly typed method as you suggest doesn't have to be a part of the core at all right now, it's easily an extension method... And it always should be (ie never part of the interface since it doesn't need to be) and based on a strongly typed poco class that is generated or pre made. You could do this now if you wanted. we can make a handy extension like that in the core but it will call back to the string + object method that you are referring to with the correct values.

[James South]

Hi Shannon,

Yeah that makes sense. 

I still wonder though about the visibility of those aliases to the user. Why is that functionality needed in a writeable fashion? Read-only I can understand. Convention would more easily allow creation of strongly typed extension methods. 

[Shannon Deminick]

I'm not sure i understand your statement?