Silverlight Friendly Name Binding

TAC posted on Thursday, January 22, 2009

Hi All,
I was just wondering if there is a way to set bind the description of a field to the friendly name entered in the Business Object. Something like...
<TextBlock Text="{Binding Path=FriendlyNames.FirstName}" Grid.Column="0"/>
<TextBox Text="{Binding Path=Data.FirstName, Mode=TwoWay}" Grid.Column="1"/>

Thanks,
Chris.

sergeyb replied on Friday, January 23, 2009

TAC replied on Wednesday, January 28, 2009

Thanks for that, it works quite well.
I am using a Resource file from my Business layer. Although I agree that it is putting some of the Presentation logic in the Business Object, the truth is that all Business Objects do it, at least any with Business Rules anyway. A business rule returns a string with an error, if you want to get technical the actual message is presentation logic, however it makes perfect sense for the Business layer to generate the message.
Our Business object properties have a friendly name so that the error messages can use them. It seems awfully redundant not to reuse them on our screens (and could leave to inconsistencies - error message says surname, field says last name). Luckily I already get the friendly names from a resource file. But I would prefer to get them from the business object instead.

-
Chris.

Justin replied on Thursday, January 29, 2009

This is one of the reason we decided to use property attributes for friendly name, max length, required, etc.

These are things that both the BO and the UI should honor and have them defined in one place.

So our BO property declarations look like:

[Attributes.TextField(FriendlyName="Company Name", MaxLength=50, Required=true)] 

public string CompanyName

In order to do localization you would simply make the FriendlyName property getter read from a resource based on a key given in the attribute initializer instead.

Like:

[Attributes.TextField(FriendlyNameResourceID="CompanyName", MaxLength=50, Required=true)] 

Of course this requires some changes to CSLA and if you want to data bind directly to the attributes in XAML you will need to do something like this:http://blog.spencen.com/2008/05/13/applying-metadata-to-wpf-bindings.aspx

RockfordLhotka replied on Thursday, January 29, 2009

You can also make the static PropertyInfo<T> fields public in scope, which makes them available to other code.

This is a good idea in CSLA .NET for Silverlight 3.6.1 because it eliminates the need for the _forceInit concept when using inheritance.

It is also a good idea when using the ObjectFactory attribute, because then the property token is available for use in your factory object (for use with the new LoadProperty() method in ObjectFactory).

However, doing this probably won't directly solve the XAML binding issue, because I don't think XAML can bind to a static value, or a field. But doing this would make it pretty easy to create a UI component similar to the way ObjectStatus works in WPF, or CslaDataProvider works in Silverlight - where the component exposes the data as a bindable property, but gets the values from the underlying business object.

You'd need a similar component to elevate any attribute-based values as well, because XAML can't bind to attributes.

JoeFallon1 replied on Thursday, January 29, 2009

Rocky,

Thanks for resolving the _forceInit concept in 3.6.1. I have not gone down this road yet but I was really not looking forward to having to explain why we would need to implement it in all of our hundreds of BOs.

Now you have just provided a hint as to how we should handle the issue for Silverlight. I want to be able to use the same BO in both environments with little to no changes. I have not been able to start a Silverlight project yet but when I do get around to it, I want things to be as smooth as possible.

Thanks.

Joe

 

RockfordLhotka replied on Thursday, January 29, 2009

ajj3085 replied on Friday, January 30, 2009

Hmm... I liked keeping them private, just because I try to hide anything not necessary.  But if making them public solves some problem, it's probably a good idea. 

Since PropertyInfo<T> has always been roughly equivalent to DependencyProperty (at least, that's the idea I got from everything posted here and in the book so far), I've always been declaring them as readonly anyway.  That's not what's shown in the book though, so if the convention does become to make them public, there should probably be lots of big warnings that they should be readonly as well.

Also, is there anything in PropertyInfo that can be changed once instanciated?  That might be a problem if they are made public as well.

RockfordLhotka replied on Friday, January 30, 2009