Have a go and play around with adding new entries, selecting various entries, start typing in either the master or the detail view, delete entries, and change the lastname to less than three characters. See what happens.
Whether you edit in the master or in the detail view, all entries are immediately synchronized.
When there is no selection, the detail view folds away, becomes read-only, and shows no values. It makes absolutely no difference what led to the deselection. BTW: We have chosen to deselect on every delete, such that we can show this effect more easily. In a real application, we would of course rather select the next entry than dropping the selection.
Kolibri makes multi-way editing and other consistent updates throughout the application very easy. You just define what your attribute represents by giving it a qualifier like "Person.1.firstname". Kolibri takes care that all attributes with the same qualifier are always kept in sync. This applies not only to their values but to all of their visual properties (validity, label, editable, and so on).
Please note that this feature works without any dependencies. No view knows any other view - nor do the models! We can add, remove, or modify any part of the application without touching the other parts and the synchronization still works!
The lastname attributes have a converter to uppercase and a validator for at least three characters. No matter where and how you change, these rules are always enforced and apply wherever the same value occurs. The visualization of validation errors is equally consistent.
Master-Detail Views come in an abundance of different ways.
Here we have a list or table as the master view and a form as a detail view. Other master-detail views might be less obvious like tabbed views where the tabs constitute the master. Then there are drop-downs, selections, radio buttons, ribbons, accordions, menus, cover-flows, tiles, and so on. The list is endless.
The Kolibri approach is always the same, no matter which of the many master-detail views we encounter. We bind the selection to a presentation model. This is so repetitive that we can delegate the work to a master-detail projector that delegates the handling of updates to the instant-update projector.
Manual testing might be appropriate in the prototyping stage, but you will quickly find that testing multi-way editing is particularly cumbersome to do manually. There is just so much clicking around and observing effects. You get bored, become unobservant and bugs creep in.
Test automation comes to the rescue, and it is quite easy to implement. Have a look at Person test that covers master-detail construction, proper selection handling, and multi-way update. We hope you can pick up the pattern how to write those tests.
You can actually run those tests live in your browser right now!