XAF - 8 - Add your own UI parts

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

The message I'm trying to convey today is really very simple: if there's something you can't do within the boundaries of XAF, it is still possible to do it (partly) outside.

As I know from personal experience, frameworks often have what I like to call a lock-in effect. Basically, you write an application based on some framework, and suddenly the customer comes along with this requirement that just doesn't seem to be possible within the framework architecture. Often this has to do with the way the framework works -- for instance, systems that are based on code generation often make it pretty hard to add extensions beyond what the framework authors had in their minds. In other cases, it is simply not possible to work with the framework's data structures, but outside its UI elements. There are lots of other problems -- it's simply something that is very common to encounter.

In a way, these lock-in effects are unavoidable. Every framework is created for a particular purpose, standardizing certain things in order to make them easier to use, but at the same time imposing restrictions on what can be done at all with reasonable effort. If you start working with XAF and then decide that the application you're writing really has all the characteristics of Doom II, then there's not much we can do to help you. Outside of that, XAF is quite exceptional in its openness. Avoiding the lock-in effect was something we targeted specifically in the XAF architecture, and if there are cases where we haven't succeeded yet, feel free to let us know and we'll do what we can.

The title "add your own UI parts" of this post is about creating new pages or forms in your applications that work with XAF data, but are simply (Web)Forms for one or the other UI platform. The important part of doing is to access data that is, by default, handled by XAF automatically, in order to work with it as you see fit in these parts you've created yourself. This is surprisingly (?) simple in XAF, basically you just have to get hold of a reference to the current running application, and you can access all the data handling classes from there.

In the ASP.NET application there's a singleton instance of the running application available through WebApplication.Instance, in the Windows Forms one there's currently no such thing -- a slight oddity I found myself when I looked into this. We will probably change something about this in the future, meanwhile you can either add your own static property to the WinApplication class (that class is declared in your code, after all), or you can pass the reference in from the controller you use to bring up your custom form or otherwise call into your custome code. A controller is the likely link you will use anyway between "standard" framework based code and your own, and the reference is easily accessible from there, so this shouldn't really be a problem.

I'm attaching a sample application to this post, which implements a custom Web Form as well as a custom Windows Form. There are controllers and actions in both applications that you can use to jump into the custom parts. The action for the ASP.NET example is available everywhere (button on the top right above the standard list view), the one for the Windows Forms sample is configured to apply to Post type objects.

Click here to download the sample application. Have fun!

Free DevExpress Products - Get Your Copy Today