My blog has moved to Microsoft Israel. Please update your bookmarks (RSS).
Update: Moved the RSS to FeedBurner. Please re-update
My blog has moved to Microsoft Israel. Please update your bookmarks (RSS).
Update: Moved the RSS to FeedBurner. Please re-update
Wow, it’s been a long time. Crazy deadlines and long commutes are to blame. Nothing to do with my laziness
I’ll be attending Microsoft Developer Academy 4.0 (Hebrew-only site, sorry). I’ll take a stab at blogging live from the event (wireless coverage permitting). See you around!
Update: Got myself a Twitter account @dudnet.
It looks like this blog just hit the front page of Google’s search results for IDataErrorInfo. I certainly hope this wasn’t caused by the Chinese attack on Google.
P.S. I didn’t abandon the PropertyChange series; the third article is to be published soon. In the meantime, check out some derivaciónes
This is the second article in a planned series of articles concerning AOP with Unity Interception and Policy Injection:
I hope you will find this useful in your work; all feedback will be greatly appreciated.
The previous article discussed an implementation of the INotifyPropertyChanged aspect using Unity Interception AOP. Today we will see how a similar approach can be applied to another interface commonly used by WPF (as well as by ASP.NET MVC).
The IDataErrorInfo interface consists of two methods:
columnName) parameter andError property.We will solely focus on the indexer, which returns error messages on a per-property basis.
The Validation Application Block allows developers to easily incorporate input validation via property attributes and/or application configuration, supporting a variety of provided validators, as well as custom ones.
IDataErrorInfo and VAB seem to be a perfect match, and have indeed been integrated. Adding Unity Interception will further simplify input validation, so that (presentation) models could be specified in the following manner:
[NotifyPropertyChanged, DataErrorInfo]
public class Contact : MarshalByRefObject, INotifyPropertyChanged, IDataErrorInfo
{
[StringLengthValidator(1, 20, MessageTemplate="First name length must be between {3} and {5}.")]
[ContainsCharactersValidator("0123456789", Negated = true, MessageTemplate = "First name cannot contain digits.")]
public string FirstName { get; set; }
[StringLengthValidator(1, 20, MessageTemplate = "Last name length must be between {3} and {5}.")]
[ContainsCharactersValidator("0123456789", Negated = true, MessageTemplate = "Last name cannot contain digits.")]
public string LastName { get; set; }
public event PropertyChangedEventHandler PropertyChanged = delegate { };
public string Error
{
get { return null; }
}
public string this[string columnName]
{
get { return null; }
}
}
Note: The implementation presented below is limited to classes derived (possibly indirectly) from MarshalByRefObject.
I recently had to add a WPF resource dictionary to a project that was previously created as a plain Control Library. I learned that:
so I created a new WPF User Control Library project and compared between the two.
Now, if you need to add WPF capabilities to your Control Library, just follow these simple instructions:
<PropertyGroup> element add:
<ProjectTypeGuids>{60dc8134-eba5-43b8-bcc9-bb4bc16c2548};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids><TargetFrameworkProfile>Client</TargetFrameworkProfile>
Hey VS team, great obfuscation job!
If you have ever developed a non-trivial application in WPF, you’ll probably find this familiar:
public class ProductFamilyViewModel : INotifyPropertyChanged
{
private bool isSelected;
public bool IsSelected
{
get { return isSelected; }
set
{
if (isSelected != value)
{
isSelected = value;
SendPropertyChanged("IsSelected");
}
}
}
private bool isExpanded;
public bool IsExpanded
{
get { return isExpanded; }
set
{
if (isExpanded != value)
{
isExpanded = value;
SendPropertyChanged("IsExpanded");
}
}
}
private bool isActive;
public bool IsActive
{
get { return isActive; }
set
{
if (isActive != value)
{
isActive = value;
SendPropertyChanged("IsActive");
}
}
}
private void SendPropertyChanged(string propertyName)
{
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}
public event PropertyChangedEventHandler PropertyChanged;
}
(This is an excerpt from a real class I’ve been working on; the actual code is bigger and uglier.)
Isn’t it sad that you have auto-implemented properties, but not the ability to use them? Wouldn’t you love to be able to do something like that?
[NotifyPropertyChanged]
public class ProductFamilyViewModel : MarshalByRefObject, INotifyPropertyChanged
{
public bool IsSelected { get; set; }
public bool IsExpanded { get; set; }
public bool IsActive { get; set; }
public event PropertyChangedEventHandler PropertyChanged;
}
This has been achieved (with varying levels of success) with DynamicProxy2 and repeatedly with PostSharp (reportedly refined in PostSharp 2.0), but what about Microsoft Enterprise Library?
At first, the Policy Injection Application Block might look like the perfect tool for the task, but looks are often deceiving; quoting Richard Banks:
Windsor and PIAB both have a shortfall that we can’t overcome. Neither of them can alter the type of a class they are providing aspects for – they simply provide proxies that add hooks to intercept method calls. We would still need to implementINotifyPropertyChangedin our class for binding to work.
Not to fret! Luckily, Enterprise Library 4.1 ships with the Unity Application Block (also available as a separate download). Unity, in turn, contains the mighty Interception Extension, which seems to be getting undeservedly little attention from developers. I guess this has to do with its poor documentation and lack of UI configuration support (expected to be added in 5.0).
None of these, however, have prevented Derek Greer from trying. His post contains a great introduction to Unity Interception (Prolegomena is definitely recommended) and quite a few insights, but sadly falls short of achieving the ultimate goal.
This article details a complete user-friendly implementation of the INotifyPropertyChanged aspect using Unity Interception AOP. It is the first in a planned series of articles concerning AOP with Unity Interception and Policy Injection:
I hope you will find this useful in your work; all feedback will be greatly appreciated.
Note: The implementation presented below is limited to classes derived (possibly indirectly) from MarshalByRefObject.
Update 2009-12-14: Dima Gershman, a truly knowledgeable colleague of mine, says go with the looks. Policy Injection wraps user objects with Interception’s transparent proxies, relieving us of the burden of manual configuration (and even improving performance!), although that comes at the price of some extra library dependencies. To be continued…
Theme: Shocking Blue Green. Blog at WordPress.com.