XAF - 2 - Customizing the default applications

This is post no. 2 in the mini series "10 exciting things to know about XAF". You can find the announcement of the series here.

In the process of creating applications based on XAF, the next step after the creation of business classes is the customization of the default applications XAF creates automatically. In many cases XAF will provide you with defaults that are as reasonable as we could make them, considering the vast numbers of different scenarios we target, in other cases we simply create something as a basis that you will have to modify for almost all applications. At lest for Windows Forms, the default container forms we use are an example of something we expect you to use as is most of the time, while for instance the layouts of the detail views will almost always be subject to change according to your application's requirements.

The largest part of customization work for XAF based applications is done in the Application Model. The Application Model is a centralized, hierarchical configuration store, which is initially filled with information gathered from a metadata analysis process in the framework. In a second step, changes to settings from the Application Model are merged in from several different sources, thereby overloading the defaults. Since the sources that changes are loaded from depend also on the application being run -- i.e. WinForms vs. ASP.NET -- it is possible to target a particular UI platform with certain settings. The Application Model is extensible, so that XAF modules can integrate their own settings into the hierarchy. Having all UI generation settings centralized in this way enables us to provide functionality on that basis, and the prominent example for that is the great localization support in XAF. You can find additional information about the Application Model here.

During the metadata gathering process, the framework finds a variety of different class types in the compiled assemblies and extracts information from those. The first way to change settings is to decorate classes with certain attributes that will be recognized by the algorithm and translated into model settings. While this is a pretty simple step, we do see a certain amount of confusion over this - it is important to realize that code attributes and model settings are, in many cases, just two different ways of achieving the same results.

XAF tries to provide application developers with a framework that lets them focus on that code which is really particular to their current project, which implements specific data storage classes, business logic around those classes and other functionality that is part of their requirements. We found it a natural consequence of this philosophy that developers should be able to configure the most important details about their classes using a code-based approach. That's why we introduced attributes in some cases that overlap with Application Model settings. Compared to code-only configuration, this adds a good amount of additional flexibility of course.

The easiest way to work with the model directly is using the Model Editor. At design time this is integrated fully in Visual Studio and can be brought up by double-clicking one of the files with an .xafml extension (see here for more detailed instructions). (Note that depending on the file you're editing you will modify settings either for both UI platforms at once or a particular one.) These are the most important nodes in the hierarchy, in descending order of importance:

• The BOModel node contains one subnode for each persistent class in your project(s) (up to the level on which you're editing the model). The settings in these nodes allow you to configure lots of parameters for the appearance of the classes in the UI.
• The Views node is where you customize the layout of the list and detail views for each data type. Be sure to click on the root node of each view to bring up the layout editor at design time! This is probably one of the most often missed features in XAF.
• The CreatableItems node has entries for those types that can have new instances created at runtime through the New action. You can either remove nodes here if you don't want a type to be creatable in this way or you can add nodes if you want to make classes creatable that aren't by default. Classes that have either the DefaultClassOptionsAttribute or the CreatableItemsAttribute applied (in the latter case with a true parameter), get CreatableItems nodes created by default.
• The NavigationItems node contains nodes for each class type that appears as a major navigation entry in the default UIs. In Windows Forms this is a button in the navigation bar on the left-hand side of the window, in ASP.NET a tab in the top part of the pages. You can modify these nodes in a similar way to the CreatableItems nodes, and the default set is constructed from those classes that have either [DefaultClassOptions] or http://documentation.devexpress.com/#Xaf/clsDevExpressPersistentBaseNavigationItemAttributetopic applied.
• The Options node is a node for assorted options supplied by the various modules. It's content depends on which modules are currently active in your application.
• The Application node provides general settings for the application.
• The Validation node is specific to the Validation module, but there will rarely be a business app out there that doesn't use validation one way or another. More on validation in article 3 of the series. In spite of the importance of the validation feature, it's not too common to have to change validation settings in the Application Model, that's why this entry is not at the top of this list.

While it is possible, and certainly common, to configure the Application Model at design time, its architecture also allows making changes at runtime. To some extent, this is even expected -- when an end user changes the order of columns in a grid, for instance, these settings are persisted in a file that is "part of the model" since it's read back into the model for the next application run. As developers, we can also use this feature by making changes at runtime. It is possible to bring up a standalone version of the Model Editor at runtime, and other changes, like certain control settings or layout changes to detail views, are persisted as Application Model "diffs". The only downside to this approach is that you'll have to merge the changes back into the design time .xafml files manually -- cut&paste in a text editor will do it, but that's still not everybody's thing.

Right, that's pretty much all I have to say for now. There are certain other topics that fall in the category of customizations to the applications, such as utilizing additional standard modules or How to: Customize a Template, but beyond the links to our product documentation these are topics for another day.

Free DevExpress Products – Get Your Copy Today