Search This Blog


Saturday, July 19, 2014

How to customize the underlying database provider options and data access behavior in XAF

I just wanted to repost my recent update to the corresponding article, because this information can interest some advanced XAF users.

This article describes some advanced customization techniques and low-level entities of the framework with regard to data access, which may be required in complex scenarios only.
So, if you just want to change the connection string, e.g. to use the Oracle instead of the Microsoft SQL Server database, then you would better refer to the Connect an XAF Application to a Database Provider article and documentation on your database provider instead. The XAF integration of supported ORM libraries is also described in the Business Model Design section of the framework's documentation.

Introducing IObjectSpaceProvider and IObjectSpace
XAF accesses data from a data store through special abstractions called - IObjectSpaceProvider and IObjectSpace.
The IObjectSpace is an abstraction above the ORM-specific database context (e.g., the DBContext used in Entity Framework or the Session in XPO) allowing you to query or modify data.
The IObjectSpaceProvider is a provider/creator of IObjectSpace entities, which also manages which business types these IObjectSpace are supposed to work with, how to set up the underlying connection to the database, create and update it and other low level data access options.

An XafApplication can use one or several IObjectSpaceProvider objects at the same time, and you can access this information through the XafApplication.ObjectSpaceProvder or XafApplication.ObjectSpaceProviders properties. Check out these help links to learn more on how to plug in custom IObjectSpaceProvider objects a well.

There are several built-in implementations of the IObjectSpaceProvider and IObjectSpace interfaces in our framework, which are usually specific to a target ORM (Entity Framework or XPO). I suggest you check out the source code of the default framework classes to better understand the role of the IObjectSpaceProvider:

Display issue with the WinForms layout customization form in v14.1.5

Please beware of the 

We sincerely apologize for all the inconvenience here.

Monday, June 30, 2014

Using a built-in lookup editor based on values from another table for editing simple property types

This is actually a variation of a solution I described in my recent A very interesting way to update and display a persistent property via a non-persistent one post, because it is again based on a non-persistent reference property filtered using the DataSourcePropertyAttribute along with a custom data source collection.
This non-persistent reference property is represented using the standard XAF's lookup PropertyEditors, which are quite convenient for providing a user with the capability to select a single value either from a database table or from an arbitrary data source. In one turn, by adding custom logic to the getter and setter of our non-persistent calculated property, we can update the stored persistent value, which does not need to be a reference to another persistent class (table), but to any type (e.g., string or integer). This may come in handy for legacy databases when you cannot really modify the schema to provide normal associations between tables.

Let's take a look at the actual code for this solution:

Thursday, June 26, 2014

Сustomizing the number of failed login attempts before exiting the application with the enabled security system

Just wanted to inform you of another improvement, which you may find helpful.

  • v2014 vol 1.5 : Official update is not yet available

Additional information:
The XafApplication class now provides the MaxLogonAttemptCount property, which is set to 3 by default. You can modify this default either in code or via the Application Designer.

I wanted to thank our customers Krzysztof and Robert for reminding us about this in the Support Center ticket. Please do not hesitate to contact us about similar gems that can improve your life as a framework developer. We are always happy to hear from you on what and how you develop, which scenarios are most important to you and what can be done to make it even better.

ViewController or Action activation for multiple Views or target object types via the TargetViewId property

I would like to highlight a small usability improvement that may help you write less and simpler code when configuring a target View for which a ViewController or an Action will be available.

Let's consider a couple scenarios where it may be helpful:
1. Your ViewController/Action should work for Views corresponding to absolutely unrelated Object1 and Object2 types (there is no inheritance between them and they are not descended from a common base class).
2. Your ViewController/Action should work for several specific Views of a certain object type, but be unavailable for other Views of the same type (e.g., be active for Object3_ListView, Object3_DetailView, but not for Object3_LookupListView and others).

Starting with version 14.1, you can implement the second scenario by setting the TargetViewId property of your ViewController or Action by providing a semicolon-separated list of Views, for which your element should be activated. Previously, you should have written the View.Id checks manually before executing your code. Please consider the following example: