XAF - Eliminating the number of Conditional “Something” (coming in v2011 vol1)

Introduction

I believe that every XAFer has used or at least heard about a set of extra modules XAF currently provides for customizing the appearance of editors used in List and Detail screens, most often against certain business conditions. As you guessed, I am talking about the Conditional Formatting and Conditional Editor State modules here. These modules are already quite old (the first was introduced in 8.1 and the latter in 9.2) and plus they provide different approaches for achieving similar goals. For example, in Model Editor, you are limited to creating Conditional Formatting rules, when with the Conditional Editor State module you can either define customization rules in code, via attributes or in the application model, via the Model Editor. Another example, the Conditional Formatting module works in List View only, when the Conditional Editor State supports both View types. At the same time, the latter module works for the Grid List Editors only, when the first module supports other List Editors, like Tree List. There are of course lots of other differences in behavior and also business reasons, like maintaining two different code bases – that forced us to think about providing a unified solution for solving the original task of customizing the appearance of editors.

When one is better than two…

As a result, and based on the great customer feedback we received in version 10.1 we provided a new Conditional Appearance module that was designed to supersede the two old Conditional XXX modules. This module not only takes advantage of both modules, but also provides some unique features that did not exist in its prototypes, like the capability to conditionally customize the appearance of Actions.

It is now 2011 and almost one year has passed since then, and of course XAF did not stand still for all this time, and so it is understandable that we want to optimize the team’s resources on supporting the old modules to better evolve our framework. So, in the upcoming v2011 vol1 release, we marked the Conditional Formatting and Conditional Editor State modules as obsolete (soft). If you are still using these modules in your solution, you will receive a warning during the compilation of your project. Although this is just a warning, not an error, and the modules will continue to work as they worked before, it is strongly recommended to remove your old rules (either declared in code or in the application model) and migrate them to the new Appearance rules, provided by the Conditional Appearance module. This is because in version 11.2, we are planning to completely mark these modules and all the stuff from them as obsolete, resulting in a compilation error and leaving you no choice, but removing the old modules from your solution. The experience of other customers, who have already migrated their rules in the past shows, that the migration will be smooth, because these Appearance rules are very similar to the old ones. In addition, there are plenty of examples in the docs and our demos, demonstrating how to implement all the possible scenarios using the Conditional Appearance module.

Let us know your thoughts!

I hope that you support and understand our decision, and will have no problems migrating the old rules. Should you have any difficulties, our Support Team will be glad to help resolve them, as always. Also, we are open to your feedback about further improvements of the Conditional Appearance module. So, if it is missing some important functionality, feel free to drop us a line in the comments to this blogs, or better yet, log your suggestions via the Support Center. We will be glad to review them.

It would be good to see the actual documentation for the Conditional Appearance module improved. At present is is very sparse. Examples are one thing but are very time consuming to find.

As for improvements, it would be good to see improved support for ListViews, we are still dependent on the old modules for this in some cases.When they are depracated we will lose functionality.

John

26 April, 2011

Dennis (DevExpress Support)

Hello John, thank you for your feedback. We agree with you and some time ago we already asked our tech writers to improve docs on the Conditional Appearance module, and hopefully we will see noticeable improvements in the near future.

About improved support for ListViews, of course, we do not want our customers to lose existing functionalities.

Could you please describe some cases or better give log suggestions in the Support Center?

26 April, 2011

John Botibol

Hi Dennis, I am a bit rusty here not having touched the Editor State for a while (Appearance does most things for me). The following 2 attributes don't do the same thing on a ListView:

The EditorStateRule hides the column Surname. As a matter of interest, the change is preserved in the Model so if you remove the rule, Surname does not re-appear.

Best wishes

John

26 April, 2011

Dennis (DevExpress Support)

Thank you for getting back to me, John. This functionality is really missing in the Conditional Appearance module. To be honest, there are only a few scenarios when it may come in handy and that is why we have not yet supported it in the new module: www.devexpress.com/issue=S35911

Feel free to add your vote for this suggestion. Meantime, it is quite easy to remove unnecessary columns using the Model Editor or with the help of a custom ViewController.

If you know other functions that are missing in the Conditional Appearance, please let us know.

26 April, 2011

Jascha

How about a tool to migrate existing formatting rules? While we can migrate anything we can have created, I would rather not ask my clients to do the same to any rules they have added.

27 April, 2011

Dennis (DevExpress Support)

@Jascha: It is of course a very good idea and I created a corresponding suggestion when the ConditionalAppearance was born: www.devexpress.com/issue=S35200