DevExpress XAF is a framework for .NET and Visual Studio developers who wants to create Office-like LOB apps for desktop, web and mobile faster and without hiring a large team.
Friday, October 2, 2015
Avoiding repetitive customizations for Views of the same type or subclasses via the Model Editor - YOUR FEEDBACK IS NEEDED
Prerequisites
Imagine you have the following data model classes:
class Party {...}
class Person : Party {...}
class Organization: Party {...}
XAF automatically generated several default root and nested Views for them in the Application Model. You can also create custom Views via the Model Editor on your own. For instance, you might end up with the following list under the Views node:
Party_ListView
Person_ListView1
Person_ListViewN
Organization_ListView1
Organization_ListViewN
Scenario
Imagine your first goal is to customize the appearance of the ListView for the base class - Party_ListView according to your client needs.To accomplish this, you locate the Party_ListView node in the Model Editor and make various customizations to its columns. In particular, 1. edit captions for the Photo, Address1, Address2 columns; moved the Photo column after the Address1 and Address2 ones; 2. made changes to the ListView node properties such as set IsGroupPanelVisible, AllowEdit and other options in the property grid.
What if your second goal is to have a similar appearance for other ListViews where Party records are shown, e.g., Person_ListView, Organization_ListView1, Party_LookupListView or even Company_Persons_ListView (see the poll questions in the end)?
Current problems and solutions
Currently, although related classes (e.g., Party and its Person descendants) originally have a similar layout and settings, that is only because they share the same set of properties and the nodes generator produces a similar output, nothing magical.
Customizations made via the Model Editor for the base View node are not automatically propagated to the Views for inherited classes.
That means that if you want to ensure a unified appearance for inherited classes, you will need to repeat the same customizations for each individual node.
That is what I would ideally love to avoid and that is the main reason for writing this post.
Proposed solution to avoid repetitive customizations in the previous scenario
1. Having done the aforementioned customizations for the base Party_ListView node, you right click on it and choose a new "Copy Differences..." command from the context menu;
2. A popup opens with a list of compatible ListViews:Person_ListView1
Person_ListViewN
Organization_ListView1
Organization_ListViewN
3. You select one or more required nodes for which you want to apply the same customizations and press OK in the dialog;
4. The base Party_ListView node customizations are copied to the selected ListViews.
Poll questions
1. Do you experience the same 'repetitive Model Editor customizations for the inherited classes' problem while doing XAF development?
2. If so, how often do you deal with it and how important is it for you?
3. What do you think of the proposed solution?
4. Do you use other solutions already or can conceive of different ways to avoid this repetition?
Subscribe to:
Post Comments (Atom)
Hi Dennis,
ReplyDeleteI'm sure we asked for view inheritance a long time ago. While the above sounds like an improvement, I would favour something that would automatically update child views whenever the parent view is altered instead of having to know and manually update all descendent views if an ancestor is changed. How about a model property on a view that specifies if it should automatically inherite its layout from its parent? That could be set via a code attribute and possibly default to a model-wide setting. Answers to your poll:
1. Yes.
2. Regularly.
3. Better than nothing but not ideal as explained.
4. Yes, see above.
Jascha
Same point of view as Jascha : "Better than nothing but not ideal"
ReplyDelete1. Yes, all the time.
ReplyDelete2. Often.
3. It's OK.
4. Changes should be propagated automatically till freeze.
1. Yes
ReplyDelete2. Almost always
3. It could be helpful, if it is easy to implement then it is a win
4. To rethink the whole concept in connection with code annotations and optional view inheritance would be better.
Same answer as Jascha - view inheritance must be applied once and auto-updated with all parent view changes.
ReplyDeleteIs this also a consideration for Detail views, or is there some way to achieve that already?
ReplyDeleteAs in your examples above but you might also have:
class Company
{
[Aggregated]
Person Person;
}
where the Person detail view within the Company detail view follows the layout of the individual Person view(or all other similar views).
Thanks for your comment. Yes, we are considering this for DetailView as well.
DeleteIn that case we will absolutely welcome any improvements in this area. I am part way developing a fairly complex XAF aplication but have not yet done much with the detail views.
DeleteI can confirm here too, that's a good solution to make a copy/or reference/or changeable reference of the default details view of the underlying object so that the work in object details view will not remake every time.
DeleteI'm very welcome your idea dennis
1. Yes.
ReplyDelete2. Regularly.
3. Better than nothing but not ideal as explained.
4. No,
To 3: add an Option:
Inherited View Changes after Class update
If true doit in xaf automatically , if false let the user the possibility to use the show difference solution.
Regards Lars
Guys, I greatly appreciate your answers and additional feedback on the ideal behavior.
ReplyDelete1. Yes
ReplyDelete2. It is important and I deal with it often.
3. I think it's good but Xpand PartialViewInheritance suits my needs better.
4. I use Xpand PartialViewInheritance.
I prefer inheritance. Good initiative...
ReplyDelete