XAF - 4 - General purpose standard modules

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

One of the main ideas behind XAF is to make the framework do lots of the work for you that you would otherwise have to do manually, even though it's tedious repetitive stuff. Of course everybody knows that if you find yourself implementing certain functionality more than once, you should abstract it into a separate library in order to reuse it across projects and use cases. In reality, this step is often not made, for a variety of reasons -- the basic ones are that it takes time and the customer isn't really paying for the time you spend creating a great reusable architecture for your next customer to benefit from.

On the other hand this is something we do very well here at Developer Express. Our products are meant to be useful in many different scenarios, and the functionality we provide is based on an architecture abstract enough to facilitate adaptation to all those scenarios. In a way, this was the subject on the interesting recent discussion you can find here, because this separation of concerns does influence what we do and what we expect/need our customers to do -- probably in XAF more so than in our single component products.

This post is about a certain group of standard modules we deliver. Some of our modules have very specific features (like the Scheduler module or the Reporting module, but others are more general purpose and make sense in almost all XAF based applications. However, these modules are not active for new solutions by default and you'll have to activate them in the application/module designer to take advantage of them. One of these general purpose modules I have already described in my previous article about Validation, here are a few more now.

The first module I want to point you at is the ViewVariants module. This module allows you to create variations of view configurations that the end user can switch in the running application -- in both UI platforms of course. The tutorial at the link above shows how to activate the module and how to configure additional view variants. It's important to point out that this is not restricted to few or many columns (the example chosen in the tutorial). You can (re-)configure everything there is to configure about a view in any of the variants. This feature is typically used to provide several different views of the same data, and it is very important when data is consumed by people in many different roles -- from the person who enters information in all columns to the controller who needs subset of the information to the executive who wants only the summaries.

Second on my list is the Printing System module. If you've worked with our components before outside of XAF, you'll recognize our XtraPrinting Library product in that name, and indeed the functionality is that which XtraPrinting provides. Why is that important? Well, it has happened to myself in the past: you have this great product planned with your customer, you have data entry functionality specified, business processes documented and somebody has drawn sketches of the reports. Great. You implement everything and test it and you see that it's fine. The first real user (as in the first person who wasn't involved with the whole prior process) gets his/her hands on the thing and says, "right, so how do I print this data entry grid?" Hm. When I first used the Printing System back in Delphi days -- Delphi 4 or 5, I think -- to work around this exact problem, that was one of the biggest real-world time savers I'd seen to that date.

Third, the security modules. Probably even more important than the other two above, I'm not going to say too much about them because they are especially well documented and also somewhat more obvious than the others. Security covers a lot of ground right now, from basic "once-in-do-what-you-want" setups to pretty detailed per-type permissions, with two different types of authentication. It's extensible as well and we're going to extend it in the future to cover more scenarios.

Now, at this point we're slowly moving towards those modules that are still more general purpose than the example of the Scheduler I gave above, but at the same time you might not decide to use them unless you have a specific requirement for them. I guess you could say that while the first three were things to strongly recommend even without a requirement, the next few respond to common requirements that you're very likely to have. So here's a somewhat shorter reference to these next four:

1. The FileAttachments module handles files that are attached to objects (duh!). This is a pretty common use case and so we decided to make it as easy as we could.
2. With the help of the CloneObject module, the end user can quickly create copies of existing objects.
3. The Conditional Formatting module can mark up list view content according to rules you configure in the Application Model.
4. Tracking everything that happens on the object level, changes, creations, deletions... is fully automatic with the Audit Trail module. In certain vertical markets this is extremely important, in others probably less so :-)

Great, that's it for this topic. We will certainly continue creating new modules as development on XAF progresses. It would be nice to see general purpose modules created by our customers at some point -- we'll get there, I'm sure.

Free DevExpress Products - Get Your Copy Today