As you’ll remember, starting from v2010 vol 1.5, XAF shipped with a preview of the Conditional Appearance module. This module allows you to dynamically configure the UI, and is designed to supersede the Conditional Formatting and Conditional Editor State modules. If you are not familiar with this module, you can get started by either watching this video or checking the demos in the XAF’s FeatureCenter. Conditional appearance customizations are very popular in business applications, one of our customers said that he has about 120+ appearance rules in his XAF application.
Anyway, the good news is that the ConditionalAppearance module will be released in v2010 vol 2 and in this post I want to walk you through some of the improvements we’ve made for this release.
Tree List Editors Support
Now appearance customizations are also supported for the Tree List Editors instead of just the Grid List Editors, as it was before. The screenshot below demonstrates a customized Tree List Editor look in both ASP.NET and Windows Forms applications:

Support for Custom Appearance Customizations at Runtime
We have also provided the capability to perform custom appearance customizations in code. In order to do this, we have introduced the CustomApplyAppearance and AppearanceApplied events into the DevExpress.ExpressApp.ConditionalAppearance.AppearanceController class. Both use the event arguments of the DevExpress.ExpressApp.ConditionalAppearance.ApplyAppearanceEventArgs type, providing all the necessary information about the current appearance customization. These events are very similar to the EditorStateCustomizing/CustomEditorStateCustomization and EditorStateCustomized events exposed in the ConditionalEditorState module, and so they can be used for the same tasks, i.e. providing appearance customizations at runtime. These events can be used to provide a different look and feel for selected and unselected cells in the grid (you can find some example code for this in this suggestion). Another example is suppressing the tab stops on disabled Property Editors. For this scenario, we even have a Code Central example, illustrating its implementation using the Conditional Editor State module. There, aren’t we good to you? 
Support for Appearance Customizations for Specific Views Only
We have also provided the capability to apply appearance customizations for specific Views only. Initially, the Context parameter of an appearance rule could only have one of the three predefined values - DetailView, ListView or Any.
[Appearance(
AppearanceItemType = AppearanceItemType.Action,
TargetItems = "Save; SaveAndClose",
Enabled = false,
Criteria = "RuleProperty = 'True'",
Context = "Any"
)]
public class MyClass : BaseObject
{
public MyClass(Session session) : base(session) { }
public bool RuleProperty
{
//...
}
}
This means that a rule can be active either in Detail Views, List Views or all Views. So, previously, we did not allow you to declare appearance rules targeted at specific Views, but now the Conditional Appearance module supports such functionality. And, based on the feedback we received, we have fixed the oversight so that you can now create View-specific rules. The Context parameter can be specified in the following ways:
|
Context
|
Appearance Rule's Activity Scope
|
Example
|
|
A predefined context - "DetailView", "ListView" or "Any".
|
Detail Views, List Views or all Views, respectively.
|
Any
|
|
A comma-separated list of View identifiers.
|
Specified Views only.
|
MyClass_ListView, MyClass_DetailView
|
|
The "Any" predefined context, followed by a comma-separated list of View identifiers.
|
All Views except the Views specified via View identifiers.
|
Any, MyClass_ListView, MyClass_LookupListView
|
|
The "DetailView" or "ListView" predefined context, followed by a comma-separated list of View identifiers.
|
All Detail Views or List Views, respectively, in addition to Views specified via View identifiers.
|
DetailView, MyClass_ListView
|
As you see, not only can you specify Views where a rule should be activated, but you also have the option to exclude a particular View from an appearance rule’s scope.
As part of this improvement, the Model Editor now allows you to type-in View identifiers when editing the Context property. The good news is you can still choose a predefined context via the drop-down in a couple of clicks:

Support for Custom Layout Items and Customizations
We have also provided the capability to conditionally hide custom layout items. Before this feature existed in the ConditionalEditorState module, but not in the ConditionalAppearance module, which allowed you to hide only layout items corresponding to the Property Editors of a business object. As part of this work we have also introduced the capability to change the font style and colour of layout items and group captions. For this purpose, the AppearanceItemType enumeration now exposes an additional 'LayoutItem' value. This is how an appearance rule will look in code:
[Appearance(
"TargetFormattingProperty.Caption.Blue",
AppearanceItemType = "LayoutItem",
FontColor = "Blue",
Criteria = "Priority = 'Low'"
)]
public string TargetFormattingProperty {
get { return targetProperty; }
set { SetPropertyValue("TargetProperty", ref targetProperty, value); }
}
and this is what it will look like in your application:

We have also introduced some minor refactorings to improve your experience when configuring appearance rules.
You can play with most of these improvements in XAF’s FeatureCenter demo. As always, we look forward to your feedback.
Well that is all for this post, ‘til next time, happy XAFing! 