Silverlight Friendly Name Binding

Silverlight Friendly Name Binding

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


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

In general, you can bind to almost anything in Silverlight, so if you BO has a friendly name property for a field, you can bind to it.  So, in your case you would have a property “FriendlyNames” that exposes an object with a property of FirstName.  However, it seems you are mixing UI logic into your BO, which may not be a good idea.  Instead, I would encourage you to use IValueConverter that would simply accept a parameter of property name, interpret it and return property description, possibly from resource file.  Something like:

Text=”{Binding Source=Data, Converter=FrendlyNameConverter, ConverterParameter=FirstName}”

 

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

cid:_2_0648EA840648E85C001BBCB886257279
Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

 

From: TAC [mailto:cslanet@lhotka.net]
Sent: Friday, January 23, 2009 12:17 AM
To: Sergey Barskiy
Subject: [CSLA .NET] Silverlight Friendly Name Binding

 

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.


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

The more I work with the 3.6.1 implementation, the more convinced I’m becoming that the static PropertyInfo<T> fields should be public.

 

That’s the way Microsoft does the DependencyProperty fields too – they are public – and for the same basic reasons. The static field is a token representing the property – both inside and outside the object itself.

 

Making the fields public allows an ObjectFactory to work nicely, provides metadata to the UI, and allows Silverlight to avoid the _forceInit issue.

 

Rocky

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

I agree that a wholesale recommendation to make them public will require some double-checking on these issues (especially in terms of what can be changed on the PropertyInfo<T> object).
 
Rocky

Copyright (c) Marimer LLC