Beware of the NullReferenceException when executing a ParametrizedAction with TabbedMDI in v14.2.6

I would like to pay your attention to the ParametrizedAction throws the NullReferenceException when TabbedMDI is used issue, which you may encounter in the version 14.2.6. 

Turning off the tabbed MDI mode can temporarily help you avoid this error, but this is not very suitable. So, I strongly recommend you download a patch from here.

Please accept sincerely apologies from our team for all the inconvenience here.

Save & Close again: To close, or not to close: that is the question - YOUR FEEDBACK IS NEEDED!

Just a quick help request to you, guys...
There was one point regarding the behavior described in my recent post at
Corrected Save & Close Action behavior on the Web in v15.1, which we were not very sure about:

#2. If the DetailView was first opened in the View mode from a root ListView, then switched to the Edit mode by an end-user via the Edit Action, then Save & Close will save the changes and return you back to the View mode instead of closing and showing the source ListView.

We received only a couple of comments on this very point and since this change is not very important to us, we wanted to make sure the new behavior meets the needs of the most users. So, I would kindly ask you take a minute to leave a comment to my blog post on the desired behavior you would like to see in this situation. Thank you in advance!

P.S.
I personally tend to think that this should be a real "close" result = navigating back to the ListView regardless the DetailView was in the View mode before or not. But you may disagree and consider this as navigating back to the previous view state in the stack...who knows...

Determining whether a security user belongs to a certain role in code becomes a bit easier

As you probably know, we already have a built-in solution for checking this condition within criteria - IsCurrentUserInRole criteria function (learn more from my blog...).
Doing the same in C# or VB.NET code is also possible with LINQ or a simple 'foreach' (through the SecuritySystem singleton), it would still be great to have a more straightforward and built-in method for this common task, especially for newbies.

Good news is that starting with version 14.2.7, this task can be done more easily. Let me quote the provided solution details from this Support Center thread:

Now, you can determine whether a user belongs to a certain role in code using the IsUserInRole extension method. This method is available for both ISecurityUserWithRoles (new Security System) and IUserWithRoles (legacy Security System) user types.

Google Maps integration in XAF Web UI - Looking for real use-cases!

UPDATED:
We've implemented the new Web Map Module in v15.2 based on the great customer feedback we received from this post. Refer to the XAF - Web Map Module (Coming soon in v15.2) article for more details.
===
We had a few requests from our users on this subject, and some time ago we described two possible integration options (a custom ListEditor and PropertyEditor) in the T195734: How to use Google Maps in XAF ASP.NET application ticket. There is nothing special here as these approaches are already well-known from XAF documentation: Using a Custom Control that is not Integrated by Default

In addition to the implementation instructions, there was a sample project that should have helped you get all the pieces of the puzzle together. It was not complete implementation by any means (some scenarios were not implemented intentionally), but rather a demonstration of how that is possible in general with an intent for users to further extend and test this solution according to your exact business requirements and Google Maps API docs :-).

Unfortunately, there was not much interest and feedback from users on this basic implementation and, more importantly, on their business requirements, nor on the info on how the Google Maps component helps end-users do their work easier. We require this essential information in order to investigate whether or not it is possible to provide a universal and useful solution for this scenario as part of the standard framework delivery.

This blog post is one more attempt to collect this information from you, guys, I greatly appreciate your input in advance. I am also writing this because I've recently extended the original example implementation by supporting a few more things, which I think the majority would want to have by default. These are: opening geo point details in DetailView after clicking on it within a a map, the possibility to not only display a point's information in detail form, but also to edit its details when we are in the Edit mode with the help of ASPxObjectPropertyEditor. I demonstrated the latest features in the video below:

If you faced a requirement to use Google Maps or any other similar map control to better meet the needs of your clients, I would greatly appreciate it if you email me at dennis@devexpress.com and tell the details of your real use-cases along with the screenshots, videos and other info. 
To formalize this a bit and make it easier for you to answer (and for us to process too), see the four simple points:

Making sure a property value is unique with XAF and XPO

I wanted to share a link to a hot Support Center discussion on the subject (it has now been unpublished by the author, sorry) with the community members as I believe this business task is not unique:-) and many others should be interested in knowing how to properly handle this.

I am going to detail technical considerations of possible solutions at the application UI and database levels depending on various configurations of your data model including inheritance mapping options (Table per Hierarchy or Table per Type) and soft deletion.

Application UI level

First of all, let's start from the UI part. How would a developer of an XAF app ensure that its end-users are not allowed to save records whose property value or combination of values are unique? 

As you know, XAF ships with a built-in validation module that provides a powerful and extendable validation engine and a large set of predefined attributes to configure common validation rules declaratively. To ensure uniqueness, you can first add the ValidationModule component into your XAF module or application via the designers and then choose from the two built-in rules: RuleCombinationOfPropertiesIsUnique and RuleUniqueValue (it is also possible to turn RuleObjectExists and RuleFromBoolPropert for the same task, but its use is not that straightforward use and I will not talk about it for now). Depending on your preferences, you can either annotate your data model classes with the corresponding code attributes, e.g.:

       [RuleUniqueValue]
       public string Name { ... }

or declare everything at the Application Model level via the Model Editor tool (learn more...). In addition, you can configure the rule's CriteriaEvaluationBehavior parameter, to specify whether to look for modified objects that are currently loaded in memory, in addition to objects in the database itself.

As a result, the XAF's validation engine will consider the rules you configured  when a data record is being saved (technically, when the View.ObjectSpace.Committing event is raised) and will throw ValidationException when uniqueness is violated. This is a special exception type, which is caught by other system controllers to display the validation error in a nice way in the UI:

This would be our topmost  or basic protection level as it handles user input only. It will not help avoid duplicates if the same data records are created in code by a developer who did not call one of the Validator.RuleSet.ValidateXXX methods. 

Corrected Save & Close Action behavior on the Web in v15.1

I wanted to inform you of a small improvement we made last week in response to this customer's request in the Support Center:

T203497 - Web - Close DetailView and navigate to the root ListView by default after executing the "Save And Close" Action

This was requested by more than a dozen of users who previously had to implement a custom ViewController like the one from this tutorial. The reason for this change was that end-users sometimes got confused after a command that was supposed to close the editing form, actually navigated you to a readonly form instead...

Technically, this legacy behavior remained from the old times when it was not possible to show collection properties in the Edit mode of the DetailView. At that time, the Save & Close Action intentionally switched to the View (readonly) mode by default and this switching was required right after adding a new object, because you could only customize these collections in the View mode. Since displaying collection properties in the Edit mode of the DetailView is now the default behavior of new projects created using the XAF solution wizard, the older behavior no longer makes sense.

Let me restate the behavior of the Save & Close Action in v15.1 and ask you opinion on it:

How to map ORM data model to another schema, e.g. other than the default "dbo" in MS SQL Server?

I just wanted to bring your attention to the recent update of one of the articles in our support knowledge, which is devoted to advanced data layer customizations - telling XAF business objects to use a different owner schema in the database.

Here we go:

Improved Error.aspx page that allows you to restart the Web application in case of critical crashes

We have implemented the subject starting with the next maintenance update (14.2.6) and it will be available in new XAF projects created using the Solution Wizard. If want the same thing in existing XAF projects, just replace the old Error page files in in <YourSolutionName.Web> project with the new ones copied from our demos or a new XAF solution.

This improvement was done based on the feedback of several customers (learn more...), and I hope your clients will appreciate this as well. That is because such critical errors may occur due to uncaught mistakes in your custom code (yes, it happens sometimes) and users could not easily continue the use of their app, as returning to the previous request page is not possible in such cases. The only possible solution for end-users was reopening the web browser or waiting for the ASP.NET session to expire, which was inconvenient. In the new version, we simply added a new "restart the application" link to the error page that calls the WebApplication.Instance.LogOff() method restarting the app.

If you want to test this right away, you can install this hot fix build:

http://downloads.devexpress.com/Share/DXP/150312/DevExpressComponents-14.2.5.15071.exe

Starting with XAF v14.2.6 the data-aware Excel export functionality is available for Grid List Editors by default

If you want to test this right away, you can install this hot fix build:

http://downloads.devexpress.com/Share/DXP/150303/DevExpressComponents-14.2.5.15062.exe

Technically, our ASPxGridListEditor & GridListEditor classes now implement the IDataAwareExporter interface that helps to deliver the data-aware export functionality added to our controls in v14.2 a few months ago. Note that our Grid List Editors support only the ExportTarget.Csv, ExportTarget.Xls, ExportTarget.Xlsx types by default. The former WISYWIG mode will be used if the ListEditor doesn't support the IDataAwareExportable interface.

JFYI for creators of custom PropertyEditors for complex ListView in-place editing scenarios in WinForms

This is just a quick note for advanced XAFers creating complex PropertyEditors in WinForms.

If your custom PropertyEditor is intended for complex ListView in-place editing scenarios (e.g., drop-down editor data source filtering), then its underlying control should support the DevExpress.ExpressApp.Win.Core.IGridInplaceEdit interface.

The most common scenarios include data source filtering (e.g., the functionality of the DataSourceCriteria, DataSourceProperty and similar attributes) and obtaining information of the currently edited record in ListView for internal purposes (e.g., obtaining object type information). Standard XAF PropertyEditors whose underlying controls implement the IGridInplaceEdit interface include LookupPropertyEditor, ObjectPropertyEditor, PopupCriteriaPropertyEditor and ExpressionPropertyEditor. You can refer to their source code for more details. In addition, you can consider checking the How to work with referenced properties via a simple drop down list instead of the standard LookupPropertyEditor (Example) example source as well.

Usability improvements for new XAF apps using XPO for data access

I would like to inform you that the next v14.2.6 update of XAF will contain two minor improvements that will help you accomplish two common tasks more easily or help you have less problems with them. Both will affect only new XAF projects created using the Solution Wizard (existing XAF projects will not be touched to avoid collisions). Also, both things were implemented based on the feedback from our users and I hope will be welcomed by them as less work to be done is left for you now.

Here I will shortly outline solution details while you can see the full information by the links below:

T191131: DevExpress.Persistent.BaseImpl - Avoid problems caused by the fact that a new BaseObject record has an empty key value until it is saved

In XAF Solutions created via the Solution Wizard, the BaseObject.OidInitializationMode static property is now set to AfterConstruction using the following code line added to the Module.cs file:

[C#]
BaseObject.OidInitializationMode = OidInitializationMode.AfterConstruction;

We do not modify the default value in the BaseObject class implementation to avoid the behavior change in existing applications.

S173546: Usability - Remove the necessity to manually call the CalculatedPersistentAliasHelper.CustomizeTypesInfo method from custom code when CalculatedPersistentAliasAttribute is used

Now, in XPO-based XAF solutions created with the Solution Wizard the following line is added to the overridden CustomizeTypesInfo method in the Module.cs file:

[C#]
CalculatedPersistentAliasHelper.CustomizeTypesInfo(typesInfo);

You can remove this line if you do not need to use CalculatedPersistentAliasAttribute.

As always, I look forward to your feedback in comments. If you know about other things that may greatly improve your experience as an XAF developer, do not hesitate to let me know.

Simplifying declaration of calculated properties in code for DataView mode with Entity Framework

Starting with v14.2.4 (and even 14.1.9) you can use the DevExpress.ExpressApp.DC.CalculatedAttribute to specify an expression used to calculate a property value of an Entity Framework class in Data View mode:

[C#]
public class Payment {    
    public Int32 ID { get; protected set; }
    public Decimal Rate { get; set; }
    public Decimal Hours { { get; set; }
    [NotMapped, DevExpress.ExpressApp.DC.Calculated("Rate * Hours")]
    public Decimal CalculatedAmount {
        get { return Rate * Hours; }
    }
   // Other data properties and logic...
}

This attribute functions exactly like the DevExpress.Xpo.PersistentAlias attribute applied to a regular business class property. Of course, properties, referenced in the specified expression (using our cross-platform object-oriented criteria language) should be persistent to be able to run an SQL query at the database level. 

To remind you of the DataView mode, this is what you will see in the SQL Server Profiler if you set DataAccessMode = DataView for the Payment_ListView node containing only the Amount column above:

SQL:
SELECT 
    [Limit1].[ID] AS [ID], 
    [Limit1].[C1] AS [C1]
    FROM ( SELECT TOP (2147483647) 
        [Extent1].[ID] AS [ID], 
        [Extent1].[Rate] * [Extent1].[Hours] AS [C1]
        FROM [dbo].[Payments] AS [Extent1]
    )  AS [Limit1]

Note that even though our entity may contain a way more other persistent properties, the query included only the two from the expression above, which increases performance in certain scenarios.
The advantage of this attribute solution is that it is easier to keep your data model logic in one place/class instead of spreading it across multiple layers, e.g., Application Model, where the DataView settings are specified:

XAFML:
<ListView Id="Payment_ListView" DataAccessMode="DataView">
    <Columns>
       <ColumnInfo PropertyName="CalculatedAmount" IsNewNode="True" />
    </Columns>
</ListView>

If you are not sure of which ListView data access mode is best for your particular screen, these guidelines in our docs will help you decide.