Cannot bind an unregistered property in xaml: a bug or a new CSLA4's behaviour?

Cannot bind an unregistered property in xaml: a bug or a new CSLA4's behaviour?

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


Cuong posted on Friday, August 06, 2010

Hi Rocky,

I have a business class like below:

public class MyClass : BusinessBase<MyClass>

{

        public readonly static PropertyInfo<int> DataProperty = RegisterProperty<int>(x => x.Data);
        public int Data
        {
            get { return GetProperty(DataProperty); }
            set { SetProperty(DataProperty, value); }
        }

        public int Data1
        {
            get { return GetData1FromData(this.Data); }
            set { this.Data = GetDataFromData1AndData2( value, this.Data2); }

        }


        public int Data2
        {
            get { return GetData2FromData(this.Data); }
            set { this.Data = GetDataFromData1AndData2( this.Data1, value); }
        }
}

In CSLA3.8 & .net 3.5, I can bind MyClass.Data1 and MyClass.Data2 in a xaml like:

<TextBox Text={Binding Data1, Mode=TwoWay} />

<TextBox Text={Binding Data2, Mode=TwoWay} />

In CSLA4.0 & .net 4.0, I cannot bind MyClass.Data1 and MyClass.Data2 like above. The application always crashes and throw an exception "Sequence contains no elements". I cannot determine in source code the place where the exception is thrown. But if I add 2 fake registered properties like below, the application works fine.

public class MyClass : BusinessBase<MyClass>

{

        public readonly static PropertyInfo<int> Data1Property = RegisterProperty<int>(x => x.Data1);

        public readonly static PropertyInfo<int> Data2Property = RegisterProperty<int>(x => x.Data2);

...

}

 

I'd like to know if it is a bug or a new CSLA4's behaviour? Must all properties be registered to be bound in a xaml?

 

RockfordLhotka replied on Saturday, August 07, 2010

Basic binding should work ok (not great) against the two properties you implemented. Since they don't raise PropertyChanged events (you aren't calling OnPropertyChanged for them) your data binding experience will be somewhat substandard - but you can address that by just adding OnPropertyChanged calls in the setters.

That's standard XAML binding I'm talking about - it can bind to normal properties just fine (with limitations if the property doesn't raise PropertyChanged).

The CSLA 4 UI components like PropertyStatus however - those require registered properties. That's how PropertyStatus (as an example) is able to get at validation and authorization results for the property.

Cuong replied on Saturday, August 07, 2010

Oh yes, I re-checked and I saw the issue resides in the PropertyStatus's bindings (not controls).

Could you modify the PropertyStatus on the way it treats unregistered properties? It should ignore unregistered properties instead of throwing an exception. Because the PropertyStatus did not throw the exception with unregistered properties in CSLA3.8. So old applications that worked fine with CSLA3.8, may suddenly  crashes with CSLA4.0 and it is hard to search in big projects to change ALL unregistered properties to be registered.

RockfordLhotka replied on Saturday, August 07, 2010

I can't see how that would be a good change. If PropertyStatus ignored unregistered properties (and there's no way for it to detect that really), then people would move to CSLA 4 and have no idea why their PropertyStatus controls were failing.

On the other hand, I can see an argument for improving the exception that's thrown when someone tries to use CanReadProperty or CanWriteProperty against an unregistered property (because I suspect that's what's triggering the exception).

Copyright (c) Marimer LLC