Search This Blog

Wednesday, October 25, 2017

Beware of the situation when a signed assembly with a business type used in the dashboard changes its version


I wanted to inform our Dashboard module users about a situation, which we missed originally:
DashboardObjectDataSource serializer fails to load a data source type when signed assemblies with a changed version are used

As you understand, it may occur only when target business types used in XML dashboard definitions with ObjectDataSource are from signed assemblies and the assembly version changes, e.g. when you deliver a new app version to the client:

 <DataSources>
    <ObjectDataSource ComponentName="dashboardObjectDataSource1">
      <Name>Object Data Source 1</Name>
      <DataSource Type="YourNamespace.YourObjectType, YourAssemblyName, Version=17.1.6498.1953, Culture=neutral, PublicKeyToken=YourPublicKeyToken" />
    </ObjectDataSource>
  </DataSources>



Currently, we recommend XAF application developers try a couple of solutions described in that thread, but they are not final solutions. We are currently reviewing them from the security point of view to make sure that the app won't be broken by passing another non-signed dll. For now, this does not seem to be the case, because business type information is obtained using the ReflectionHelper API from the already loaded assemblies, which are protected by the default .NET mechanisms. We just want to double-check or see if there are more suitable options. Ideally, I wish this to be working transparently for an application developer without the need to resolve any assemblies or types manually.


Your feedback is needed!

Have you experienced this behavior in your Dashboard apps? How do you currently cope with it? If there are existing solutions, share their details and also elaborate on their costs. Your feedback is greatly appreciated.


Thursday, October 19, 2017

How to group validation rules by a business type in Model Editor

If you want the same UI as in the screenshot below:


implement a few code lines in YourSolutionName.Module/Module.cs file, as follows:

using DevExpress.ExpressApp.ModelEditor;
using DevExpress.ExpressApp.Validation;
using DevExpress.ExpressApp.Model;

namespace MainDemo.Module {
    public sealed partial class MainDemoModule : ModuleBase {
        public MainDemoModule() {
            InitializeComponent();
            ModelEditorGroupingHelper.Instance.RegisterNodeGroupPathDelegate(
            typeof(IModelValidationRules), node => DefaultGroupPathCalculator("TargetType.Name", node));
        }
        public string[] DefaultGroupPathCalculator(string propertyName, IModelNode modelNode) {
            string groupName = "";
            object propertyValue = ModelEditorGroupingHelper.Instance.GetPropertyValue(propertyName, modelNode);
            if(propertyValue != null) {
                groupName = propertyValue.ToString();
            }
            return ModelEditorGroupingHelper.Instance.SplitGroupPath(groupName, modelNode);
        }
        //...
    }
}

This is just one example of the Model Editor nodes grouping customizations that you can achieve with the ModelEditorGroupingHelper  API.

I remember our loyal customer Mario Blataric doing magic using this helper for his specific project needs (multi-level grouping of Actions by Controllers and their namespaces/functional blocks). If you have similar needs in your project, feel free to contact our support team so we can help you make your life easier.

Tuesday, October 10, 2017

ImmediatePostData attribute support in XAF Mobile v17.1.7

I am happy to inform you that starting with version 17.1.7, XAF Mobile (CTP) supports ImmediatePostDataAttribute. You can see how it works in action using our https://demos.devexpress.com/XAF/MainDemoMobile/ demo in the Payment object's View. 


You are welcome to download the latest version and test this feature in scenarios you are interested in. As usual, your feedback is greatly appreciated. Do not hesitate to submit tickets in our Support Center.

NOTE: Automatic updates will not work for non-persistent calculated reference properties due to an OData specificity.