Search This Blog

Thursday, January 8, 2015

Model.XAFML and storing XAF application UI settings in the database

As we are improving our newest "Persisting UI settings in the database" feature (quickly learn more about it from this video or blog), I wanted to pay your attention to the ModelDifferenceDbStore - Always take into account the latest changes made to the Model.XAFML file at design time ticket I created based on the users feedback. Let me quote myself from that thread:
Prerequisites

By default, starting with v14.2, all new XAF WinForms projects will store administrative (Model.XAFML) and user differences in the database tables (ModelDifference and ModelDifferenceAspect). 

This built-in option stems from the How to: Store Model Differences in Database example we had in the past.
This new behavior is plugged-in if the Security System is enabled in the Solution Wizard and is technically done by subscribing to the CreateCustomModelDifferenceStore and CreateCustomUserModelDifferenceStore events within YourSolutionName.Module.Win/Module.xx file. Refer to the eXpressApp Framework > Task-Based Help > How to: Store the Application Model Differences in the Database article for more details.

Problem description
As of v14.2.3, the contents of the Model.XAFML file are once read during the first application run and are stored in the database. Thus, any subsequent changes to the Model.XAFML file during development will not be re-read into the database or ignored. This feature request is for improving the developers' experience when this feature is in use.

Current solutions
Take special note that to start reading subsequent customizations from the Model.XAFML file at every application run as it was in the past, you will need to backup and then drop the existing ModelDifference and ModelDifferenceAspect tables in  your test database on your development machine.

Here we go:

1. Do not subscribe to the CreateCustomModelDifference event (and thus disable storing the Model.XAFML file contents in the database) while debugging. You can use either the preprocessor directives or the System.Diagnostics.Debugger.IsAttached property for that purpose (see the code below).  
2. Perform global/administrative Application Model customizations using the runtime Model Editor instead of making changes to the Model.XAFML file at design time (see the code below). 
// Example code for #1 and #2. private void Application_CreateCustomModelDifferenceStore(Object sender, CreateCustomModelDifferenceStoreEventArgs e) { #if !DEBUG e.Store = new ModelDifferenceDbStore((XafApplication)sender, true); e.Handled = true; #endif } // Example code for #2 only. private void Application_CreateCustomUserModelDifferenceStore(Object sender, 
CreateCustomModelDifferenceStoreEventArgs e) {  
bool isSharedModelDifference = System.Diagnostics.Debugger.IsAttached;
e.Store = new ModelDifferenceDbStore((XafApplication)sender, isSharedModelDifference); e.Handled = true; }
3. Make customizations in the Model.DesignedDiffs.xafml files of your modules where possible. This solution is possible in certain scenarios only, because the Application Model is fully initialized from used modules and application settings only in YourSolution.Win project.

4. Use the application UI to edit administrative settings. In order to do this, you must add the ModelDifference and ModelDifferenceAspect classes into the navigation system as described at eXpressApp Framework > Concepts > System Module > Navigation System.


5. Make required customizations using the runtime Model Editor in the users model and then manually copy settings from the current user to the shared model as described in #4 (it is also possible to manually copy the contents of the Xml column in the ModelDifferenceAspect database table, but this is a much more complicated and advanced task for which we do not provide instructions for). 

Future considerations

At first, in one of the next minor updates, we can modify the default XAF project templates to disable storing the Model.XAFML file contents in the database while debugging (see solution #1 above). 
A more complicated solution would be always reading the Model.XAFML file, but not storing it in the database, and instead introducing an intermediate model layer whose contents will be stored in the database and are always available for customization from the application UI. See Nate Laff's comment in the S32444 thread for more details on this idea. Technically, it can be done using the CreateCustomModelDifferenceStoreEventArgs .AddExtraDiffStore method when handling the CreateCustomModelDifferenceStore event. 

See Also



If you have any other suggestions or questions on this feature, please let us know via the Support Center. Your feedback is greatly appreciated!

No comments:

Post a Comment