Search This Blog

Wednesday, December 30, 2015

EF - Use of complex types that are not registered in DbContext and have no key property

I want to highlight a minor usability improvement built into v15.2 for our Entity Framework fans. This is all about a simpler integration of complex types without keys (learn more from EF docs...). 

The situation is already pretty much summarized in the Support Center, and here I just want to re-post the main details. To begin with, consider the following EF classes:

[C#]
public class Product { public Product() { PriceRange = new Range(); } public Int32 ID { get; set; } public String Name { get; set; } public Range PriceRange { get; set; } } public class Range { public Range() { } public Decimal Low { get; set; } public Decimal High { get; set; } }
public class EFDemoDbContext : DbContext {
    ...
    public DbSet<Product> Products { get; set; }
    ...
}

Note that the Range class has no key property and Entity Framework does not map this class to a separate database table. By default, properties of such a class persist in the table mapped to the parent Product class, where the Range type property is declared. So, the Product table will have the ID, NamePriceRange_Low and PriceRange_High columns:

Wednesday, December 23, 2015

The GetObjectsNonReenterant error for security permissions with complex criteria - Fixed in v15.2.5

In v15.2.5 we have made improvements at both the XPO and XAF levels to avoid the Entering state 'GetObjectsNonReenterant' from state 'CommitTransactionNonReenterant, CommitChangesToDataLayer' is prohibited due to state 'CommitChangesToDataLayer' error that might occur while evaluating security permission criteria involving collections during the object saving procedure (S170995). Our previous attempt was unsuccessful and I apologize for this and all the inconvenience this has caused you and your business.

Our new low-level solution does not require extra options on your side, and I invite you to test a new 15.2 build containing these improvements: 


I am looking forward to hearing from you on how these improvements work in your real projects after installing this build and running the Project Converter tool. Thanks in advance!


Tuesday, December 22, 2015

MediaDataObject - Declaring images as object references instead of byte array

In v15.2 we have introduced the new MediaDataObject business class. The use of this type mainly reduces traffic in Web apps because images are cached in the browser cache (compared to images declared as byte[]).  

We have invented this solution when optimizing the new Web style performance on mobile devices. 
For instance, in our XCRM demo application (installed to C:\Users\Public\Documents\DevExpress Demos 15.2\Components\eXpressApp Framework\XCRM\, by default) the avatar picture in the top right corner is implemented using MediaDataObject:



Both WinForms and ASP.NET Image Property Editors are used automatically for properties of the MediaDataObject type, the delayed loading is also always enabled - no special attributes are required for this. However, you still can apply the ImageEditorAttribute to customize the editor's options. 

XPO and EntityFramework versions of this type are available in the Business Class LibraryRefer to the eXpressApp Framework > Concepts > Business Model Design > Data Types Supported by built-in Editors > BLOB Image Properties article to see example property declarations for your favorite ORM.

Monday, December 21, 2015

JFYI - New RefreshXXX methods allowing to reload the underlying data source of a View or ViewItem

Just wanted to make sure you are aware of this small usability improvement, which will help you accomplish daily development tasks easier and in more intuitively.

From https://www.devexpress.com/Support/Center/Question/Details/S170756 (done in v15.2.4):

The following methods are added to the View and ViewItem classes:[C#]
public virtual void RefreshDataSource()
public void Refresh(bool refreshDataSource)
Internally, the Refresh method calls RefreshDataSource when the refreshDataSource parameter is set to true.

The RefreshDataSource method overloads are:
ListView.RefreshDataSource -  calls the CollectionSourceBase.Reload method;
DetailView.RefreshDataSource  - calls the IObjectSpace.ReloadObject method and passes the DetailView.CurrentObject object to it;
ListPropertyEditor.RefreshDataSource - calls the ListView.RefreshDataSource method;
DetailPropertyEditor.RefreshDataSource - calls the DetailView.RefreshDataSource method.

Avoid auto-saving a master when a new non-aggregated child is created and making the New Action available for many-to-many lists

In v15.2.4 we have added the LinkNewObjectToParentImmediately property to the XafApplication and NewObjectViewController classes. 

By default, XafApplication.LinkNewObjectToParentImmediately is set to true to keep the behavior of existing applications unchanged (a new object linked to the master object is created and the master object is committed when the New action is executed in the nested List View). However, in new applications created in the 15.2 version, the default value is overridden to false in code generated by the Solution Wizard.

Use XafApplication.LinkNewObjectToParentImmediately to change the behavior globally (note that this property is hidden in the Application Designer and you can set it only in code). Use NewObjectViewController.LinkNewObjectToParentImmediately to change the behavior for a specific View. The behavior of aggregated collections is not changed.

There are several positive results from this LinkNewObjectToParentImmediately = false change:
1. A reference to the master object is visible in the new child object immediately. 
2. The master object is not committed and the link is not created when the New action is executed in the nested List View. At the database level that means that the reference to the master table is not added to the new child record immediately. The link is created later when the child object is committed. To keep the link, a user should save the master object; otherwise, the unlinked child object will be saved.
3. The New Action is now available directly in the nested ListView or the Link dialog for many-to-many XPO associations!

There were a lot of customer requests for the last two things, so I hope you will like this news. Please let me know what you think in comments.



Monday, December 14, 2015

DashboardView - Allowing end-users to delete created dashboards via the application UI

In v15.2.4 we have added the DeleteDashboardsController which provides the DeleteDashboard Action. This Action is located in the Tools category and invokes a popup dialog with a list of all dashboard views defined in the user's model differences.

In this popup you can select one or more dashboards and click Delete to remove them. The DeleteDashboardsController.CanDeleteParentGroup property specifies whether or not the dashboard's parent group is deleted when you remove the last dashboard in this group. 

The DeleteDashboard Action is active when there are dashboards that can be deleted and the EnableCreation property of the Options | Dashboards node is set to true in the Application Model.


Previously, it was only possible to manage these user-defined dashboards via the Model Editor or in code. So, I hope you will now be able to enable this feature for your clients without the fear of being overloaded with support calls about removing unwanted stuff.

You can find more information on this XAF feature in the online docs here:

XPO ORM Data Model Designer and Wizard FAQ

My fellow colleague Michael has recently written an article based on the most popular support calls regarding the visual designer that XPO ships with, for editing visual data models. Some things may already be known to you, but others are worth repeating and I hope you will find this short doc helpful:



How to hide or filter out certain types from the drop-down editor for the System.Type properties

I want to share my recent article on the subject that demonstrates yet another example of how flexible and powerful XAF really is. There, I will describe three possible ways of accomplishing the same task, starting with the most recommended platform-agnostic solution at the business model level (write once, work everywhere) and finishing by manipulating end control properties in the UI for certain platforms and contexts. 


So, let me quite myself from this KB article in our Support Center: