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!

6 comment(s)

Hi Oliver.

Is possible to add custom ui parts (user controls) inside a DetailView generated by xaf?


29 May, 2008

Well, we are experience two side lock effects:

- Object space creation logic and caching problems

- No real support for transactions (outsides of 1 Window - 1 Object Space)

29 May, 2008
Oliver Sturm (DevExpress)


Of course it's hard to say anything specific based on your short comment. But... well, the "creation logic" is exactly the same as you'd use in an application that's based on XPO. I see how it might not be immediately intuitive depending on your background, but it is certainly something that has been proven to work in thousands of applications. Caching problems - not much I can say about that, apart from pointing at the many articles and knowledge base entries we have on caching in XPO and XAF.

I don't understand your comment about transactions. Again, this is based on the XPO derived logic of Units of Work, which offer transaction logic on the object layer. What you do with your object space, where you pass it around and even where you retrieve it from is entirely up to you, so I can't really guess what your problem is in that regard.

Thanks for commenting anyway ;-)

29 May, 2008

Hi Oliver,

Right, my comment was a litle bit too misleading, let me give you the example:

- Transaction (point 2): Suppose you have two domain objects: Customer and Order with lots of details and logic. Separately, this works fine in XAF using biz logic, controllers and actions. Now suppose that I have a process "Create an order" that consists in two steps: Create or update the customer and  create an order for the customer. This is just a simple example but the real situation can be quite complex. Think of Wizards in this case...Obviously, the logical approach would be to launch the first View/Window with customer View details and logic, and then as step 2, the Order View details, the user should be able to go back to the customer (step 1), etc. The whole transaction consists of the two mentioned views in this case. Obviously, there are workarounds but in complex and especially changing processes, this starts to be too cubersome. We hope that with the implementation of the MS Workflow .NET framework in XAF the situation will be improved.

30 May, 2008
John Pattison

Hi Oliver,

I just wanted to drop a note to say that I've really been enjoying this series of posts.  My company is currently using XAF to implement a large line of business application for one of our most important clients.  These posts have been very helpful.


30 May, 2008
10 exciting things to know about XAF - eXpress App Framework Team

Pingback from  10 exciting things to know about XAF - eXpress App Framework Team

22 August, 2008

Please login or register to post comments.