Search This Blog

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:

Tuesday, June 3, 2014

Using a control that is not integrated by default

XAF is designed as a highly extensible and customizable framework. So, in most cases, the task of integrating a WinForms or an ASP.NET control is quite simple. You can integrate a DevExpress control that is not supported by default, a third-party control, or your own custom control. Generally, you should implement an abstract entity (ListEditor, PropertyEditor or ViewItem) that wraps the control and serves as an adapter for the XAF infrastructure. You can also customize a template and place the control in the desired location.

To help you choose an appropriate solution depending on your business scenario we have created a table that lists typical tasks and provides links to relevant examples:

I hope you find this new documentation helpful.