Search This Blog

Showing posts with label XAFML. Show all posts
Showing posts with label XAFML. Show all posts

Monday, July 15, 2013

Providing predefined values in the property inspector for a custom application model attribute

As you probably know, XAF Application Model is flexible enough to allow you to extend it to store own UI and behavior options (learn more...) for all users or individually. Today I would like to spent a few minutes to show you one of the possible approaches to provide default values for your custom options.

Scenario
Let's consider a real-life scenario, which I believe many of you deal with in XAF: you create a validation rule via the Model Editor and specify the TargetContextIDs property to tell XAF when to check it:



Technically, there is a string property declared in the IRuleBaseProperties interface:

        [Required]
        [Category("Behavior")]
        [DXDescription("DevExpress.Persistent.Validation.RuleBaseProperties,TargetContextIDs")]
        string TargetContextIDs { get; set; }

Our goal is to provide a drop down editor in the property inspector (instead of the plain text box) to be able to choose the predefined "Save" or "Delete" strings instead of typing them manually.

Solution:
One of the possible solutions is to use the standard .NET Framework TypeConverter mechanism. I should explicitly note that there are many other possible solutions for the same in XAF, and I just would like to describe this one because of its simplicity and popularity even outside of our framework.

Basically, I will perform the two simple steps:

1. Create a custom TypeConverter by descending from the standard StringConverter class and overriding a couple self-explanatory methods (learn more...):

public class DefaultValidationContextsConverter : StringConverter {
        public override bool GetStandardValuesSupported(ITypeDescriptorContext context) {
            return true;
        }
        public override StandardValuesCollection GetStandardValues(ITypeDescriptorContext context) {
            return new StandardValuesCollection(Enum.GetNames(typeof(DefaultContexts)));
        }
    }

2. Mark the required model element property with the TypeConverterAttribute passing my custom converter as a parameter:

        [TypeConverter(typeof(DefaultValidationContextsConverter))]
        string TargetContextIDs { get; set; }

That's it.


Results
You can see what we are after in the screenshot below:



BTW, this small improvement will be available starting with in the next minor update (13.1.6), and it should improve usability for beginners in this scenario.

If you know about other scenarios in our framework where usability can be tuned, do not hesitate to let us know as we will be glad to see to it.


Alternative solutions
Depending on your business requirements it would be possible to achieve the same or similar effect using other techniques:
1. a custom UITypeEditor;
2. DataSourcePropertyAttribute/DataSourceCriteriaAttribute;
3. Domain Logic,
to name just a few.  I hope to talk through them in the future when I have some time.

Thursday, October 25, 2012

About "unusable nodes" in XAF Application Model

The problems with unusable nodes may normally occur only if model elements are not defined in the application model. For instance, you might move Web differences (one layer) to a WinForms or platform-agnostic module project (another layer with a different schema that knows nothing about Web). Or you might remove certain model elements from the application model yourself. More information on this can be found at Why application model differences can be removed into the UnusableNodes.xml file

Normally, these problems should not occur at all if you use the Model Editor and Merge Model tools and do not edit the XAFML files manually.
You can learn more about means of detecting unusable nodes at http://documentation.devexpress.com/#Xaf/CustomDocument3327

So, these are three simple steps you can follow to avoid any problems:
1. Use Model Editor and Merge Model tools to perform operations with the application model;
2. Do not edit XAFML files manually unless you are absolutely certain of what you are doing;
3. Verify that XAFML files do not contain references to removed custom model elements extensions

If this information does not help you to fix unusable nodes in your model, you are welcome to provide us with the XAFML file (or rather a small sample project) before unusable nodes appear + exact steps that cause it + the XAFML file after executing these steps. We will be glad to help you resolve this.