Search This Blog

Monday, July 29, 2013

Short vs Long View identifiers in version 13.1 (MUST READ)

Let me quote myself from the Core - Introduce an ability to have two or more classes with one and the same name, but declared within different assemblies thread:

"After receiving customers feedback, we decided to change our original implementation (it exists in versions 13.1.3-13.1.5 only) to completely avoid a breaking change here for existing customers (optionally refer to the Core - Make it possible to find a View node by its short identifier ticket for more details on the consequences of the previous change and conflict resolution options).

So, starting with version 13.1.6 the generation mechanism will stay unchanged (short identifiers like Customer_ListView will be used), while having the capability to resolve a name conflict in advanced scenarios (see the updated description of this thread).

According to all our estimates (tickets in the Support Center and other stats), the number of people migrated to version 13.1 and who already started using long identifiers should be small. 

If you already migrated your app to 13.1, it will be required to change long identifiers to short ones after 13.1.6 is out and ONLY in places where you compared View.Id == "MyObject_ListView" in code (the rest should be automatically resolved!). We do not think that it should affect many developers (we only had a single customer call as of now), because the previous conflict resolution options we introduced should cover 95% of cases. 

If you are upgrading your app to version 13.1.6 directly, no changes will be required from you at all. In any event, if you experience any difficulties with this upgrade, our Support Team will be happy to help you resolve all problems.

I want to thank you all customers who provided their great feedback during this time and also want to apologize for all the inconvenience here."

Here is what you can do if you encounter such a naming conflict in your app:

"Starting with version 13.1.6, you can use classes with the same short name but different full names in the same XAF application (e.g., you have your own YourSolutionName.Module.Customer class and also want to use the Customer class declared in a third-party module).
To register classes with a name conflict, use the static DevExpress.ExpressApp.Model.NodeGenerators.ModelNodesGeneratorSettings.SetIdPrefix(Type type, string prefix) method.
This method affects two types of identifiers:
     - Views identifier (e.g., prefix_ListView);
     - Identifiers of Actions defined via the ActionAttribute (e.g., prefix.MethodName).
Take special note that you need to use this option very carefully if you have existing Application Model differences declared for conflicting classes. These model differences will have to be updated according to the specified prefix."

Short Summary
Our original solution used long identifiers everywhere and this new algorithm did not require changes in your code, except for a single scenario: when you compare View identifiers in code like View.Id == "MyObject_ListView" directly in your code.

We come to the conclusion that it may be inconvenient for our customers to modify their code to use the automatic conflict resolution options we introduced, even though this was quite rare scenario and code changes could be done automatically using the Visual Studio Replace dialog facilities (via regular expressions).

So, starting with version 13.1.6 there will be no change at all required = short identifiers like Customer_ListView will be used as before.

You can download the 13.1 hotfix with the described changes from here:
The official 13.1.6 update should be available in a few weeks (I cannot promise the exact release date at the moment).

No comments:

Post a Comment