XAF - 6 - XAF Extensibility Points

XAF Team Blog
27 May 2008

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

XAF is a highly modularized and extensible platform. This is quite obvious as soon as you start creating your own application based on XAF -- there are lots of standard modules that add functionality, there's the way XAF picks up elements you create yourself and makes them part of your application. What does extensibility really mean with regard to XAF?

Generally there are two ways people think about extensibility. Looking at your own applications, this might be easy for you to see or hard, depending on the approaches you've been using. If your projects are the kind where you create some forms or pages in VS, drop UI elements on them and hook up a few events, then extensibility with regard to your own applications is probably quite meaningless to you. On the other hand, if you have a few helper libraries with reusable functionality that you utilize across various projects, or if you've even developed your own framework in the past, you'll easily see what extensibility on the application/project level is about: the ways you have to extend the application beyond what the framework offers out of the box. If one of your helper libraries facilitates data validation, how easy is it to create application specific validation for a particular project? If your framework creates type specific data entry forms for you, how easy is it to modify these if the need arises?

When a certain question of extensibility on the application level comes up a few times, you start thinking about extending your framework or helper libraries instead of making project specific changes all the time. That's the second level and usually it's a lot more abstract since you have to think about more than one use case at the same time. You might also decide that extensibility in some areas is better left on the application level. Certain visual case-by-case approaches to solving application level problems can be very hard to abstract in a meaningful way, so that the advantage of having framework functionality is offset by greatly reduced ease of use.

In XAF, extensibility is often on the framework level. At the same time, we feel pretty confident in saying that extending on the framework level in most cases doesn't result in added abstraction to the extent where it costs you a lot of additional time to do it. Basically you are doing per-project work, only with the added benefit of reusability across projects. The reason for this is the strong structure an XAF solution has by default:

  1. The Module project is UI independent, so it is clearly the place where most functionality should go, if possible.
  2. Our UI abstraction layer makes this convenient for a large set of use cases that would otherwise be UI specific.
  3. Additional modules specific to the two supported UI platforms provide other places to put UI specific code.
  4. Many existing modules add functionality orthogonally
  5. It's a psychological thing -- the way the platform works is the natural way to go for your own extensions

Of course, in the end it's your decision -- if you want to add your extensions all over the place, go ahead! :-)

Now, on to something more practical: a list of extensibility points in XAF. I'm probably forgetting something, but I hope this list is still an interesting summary.

  • The Validation System is extensible, I've covered this before in post 3 of this series.
  • It is possible to make your own controls (or other 3rd party vendors' controls) work with XAF. There are several examples of this in the XAF documentation, http://documentation.devexpress.com/#Xaf/CustomDocument2659, http://documentation.devexpress.com/#Xaf/CustomDocument2679 and http://documentation.devexpress.com/#Xaf/CustomDocument2678. There's also a demo that gets installed with XAF (in the Demos subfolder of your installation) that implements the custom editors described in the documentation.
  • The XAF Security System is extensible in many different ways. It uses separate strategies for authentication (based either on your own database or Active Directory) and authorization (simple and complex). For each strategy we currently deliver two implementations out of the box and you can create your own. We have several permission types and it is also possible to create your own permission types to use with our Complex Security implementation. Mostly those things involve creating your own class derived from one of our base classes and making sure it's instantiated in the right place. There's some info about this in places in the documentation, but we definitely need samples for this -- right now I'm afraid the source code is your best friend (not a bad one, mind you, but still not quite something that fulfills my quality expectations).
  • The Application Model is extensible, so you can use it to integrate your own application or module specific options and benefit from the functionality the Model offers, such as localizability. This is probably most interesting if you create your own modules to give to others, or at least to reuse in a large variety of different projects.
  • XPO, the object/relational mapping system that is the basis of the data persistence functionality in XAF, has an abstraction of the "drivers" used for the actual database access on a low level. There's already a very impressive collection of almost 20 different such "providers" included in XPO, and these are abstracted so well that the file size of the largest provider implementation is currently at only around 30000 bytes (the smallest is just 6207 bytes, btw). If you are interested in creating a provider to hook up with a database system we don't support yet, I recommend you have a look at the existing source code -- it might be much easier than you think.

Right, I'll stop at this point. As I said, there's probably something I'm forgetting, and as I described above, the definition of what constitutes an extension to a framework is not entirely cleary anyway, so I'm sure there are a lot of things that I could mention here. Feel free to suggest additional extensibility related entries for this list!

Tags
1 comment(s)
Anonymous
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.