The problem
This is an eclipse RCP application that uses the well known MVC pattern. The data model is hierarchic and several editors can be opened at different levels. The problem is that we have some transversal data that can be viewed along the tree structure. How can a view be always updated against users editions ?Considering the following structure:
- root
- node1 - use transverse data X, Y
- node2 - use transverse data X, Z
- Editor on node 1 is opened
- Editor on node 2 is opened
- Some changes are made in editor 1 on transverse data X
The editor is "dirty". - Some changes are made in editor 2 on transverse data X
The editor is "dirty". - Editor 1 is saved.
Solving the problem
We shortly came to the fact that an event should be fired when the data model is changed. Editors are registered to listen for those events to make them aware that they should reflect changes. This is not the complicated part of the problem.The "reconciliation" algorithm that the editor should implement is not trivial.
This was the time to stop trying to code it, step up the team in front of a blank white board and use TDR[1] to help us specify with some examples.
The white board
After a short discussion, we found a notation to represent data attached to an editor:- Saved
- saved data before any edition
- Modified
- modified data during edition. This is typically a bean that is tied on UI components
- Data model
- the new data model that is embedded in the event to alert editor that data changed
- Output
- the output of the algorithm: the reconciliated data
Then we started to scratch on white board. The white board has been "saved" on this sheet:
Then we set up test cases from simple to complex (1.). For each of them, we specify data (2.) as couples: CA, DA (Clé (key), Data) and CA', DA' for modified data.
The final algorithm emerges in the box (3.). The result is simple:
- if the "Saved data" is the same than "Modified data"
- "Output" should be set to "Data model"
- otherwise
- "Output" should be set to "Modified data"
Lesson learned
- TDR[1] is helping emerging conception
- Examples from a TDR[1] session are capitalized in unit tests (in our case)
- This TDR[1] session became the technical documentation (because the client want a technical documentation)
- Our examples remains generic because we found it useless to represent real data (a collection of objects
- TDR[1] is helping to make the implementation of a solution simpler
- The client were intrigued to see programmers out of their usual 'behind-the-screen' position ! It helps our team to show what we were working on.
[1]: Test Driven Requirements ou spécifications dirigées par les tests.