Question

Best practice for Save&Cancel dialog with associated objects

2

Hi all, I quite often stumble across the following 'standard problem' for modeling an edit/new dialog. I have this domain model: So, essentially a Category has a n:m relation to a Person with an attribute PersonRole. Now when I start with the New and Edit dialogue I end up with this design: In the dialog I want to change the Category name and add/delete Persons from the category. Now the problem is: how can you get the Add and Delete functions to properly work with the Save and Cancel Buttons (i.e. Cancel should roll back ALL changes, and no changes are persisted until pressing Save). I would really like to read how others solve this problem with minimal effort. regards, Fabian

asked 2017-06-22

Fabian Recktenwald

4 answers

Chris de Gelder · Answer 1 · 2017-06-22

The only way to solve this is change the domain model according to what to want to achieve and that is not the intuitive version and the not the one closest to reality.

In your case the association Assignment_Category is owned by Assignment. The Assigment is immediately created and committed to the database after adding and assignment and before pressing save on the main screen.

You can solve this by making a reference set from category to assignment thus making category the owner. That will make your domain model more complex and less self explaining because you don't really have a reference set (none of the assignments is used twice) by you want to be category the owner. In a microflow you can retrieve the assignment 'from memory' and not yet being stored.

This behaviour is powerful but causes 'wrong or contaminated' domain models and it should be a big improvement if this is solved in a future version.

Andrej Koelewijn · Answer 2 · 2017-06-23

There are 2 basic approaches to implement the behavior you are looking for:

* Add a non-persistent entity to store the relationship changes (Assignment) while you edit them, and copy them to persistent versions in a microflow triggered by the save button.

* Add a status field to the assignment entity that by indicates if something is in 'draft' status, or has been saved by the user. Upon the user pressing save you change the status from 'draft' to 'saved'. This allows you to delete 'draft' objects on cancel.

Rom van Arendonk · Answer 3 · 2017-06-22

In my opinion, the most common occurrence of this is the Order-OrderLine pattern, where you create an Order and in the Order, you also create OrderLines in a grid. This is one of the points where I sacrifice usability for ease of implementation. I tell users that when they press a save button, it gets saved into the database. Creating Assignments then has a save button, and I simply commit it. Now, if the Category get cancelled before it has been saved, it should also delete it's associated Assignments, so I set delete behavior. This is usually acceptable.

Nikel Kruizinga · Answer 4 · 2017-06-22

This will come up in almost every project, and every time the people involved may make completely different claims as to what behaviour makes the most sense. You seem to fall into the same trap where you say "to properly work".

Different applications handle this problem in different ways, there is no standard solution.

As to how to achieve the functionality you desire in Mendix, this will just take a lot of work, there is no easy solution. you will need to create your own model (as in the M in MVC) to use as context for screens in which you are able to store the state you actually want to store (what is committed, what is not).

If you would make the argument that Mendix should implement the behaviour you desire out of the box and offer the option to just configure to use this I would completely agree with you.