Data Dialog

Motivation

Data Dialog is a simplified and practical design to retrieve information from the User
by means of a modal dialog. It is generally used to retrieve preference information.

To use a Data Dialog, the following constraints must be respected:

  • It must be Modal (i.e. when visible, interaction with the rest of the application is prevented)
  • It only allows Accept (Ok button) and Reject (Cancel button) operations, not Apply
  • It does not need to synchronize with the application state while visible.

Data Dialog is different from Local Model. A Local Model is a real Model that is
connected to the View through notification, but has simply been copied to preserve
its initial state if changes are reverted. Data Dialog, on the other hand, is simply
a View with an API to populate or retrieve information from its widgets in
a trivial representation.

Design

Data Dialog object is instantiated, and its widgets are populated through an
appropriate method call set_content. Data is passed in a trivial representation
(e.g. a properly keyed dictionary) as an argument of this method.


Data Dialog - 图1

The dialog is then shown to the User. As explained in the Motivation, the show
operation must block and produce a modal dialog. The User can interact with it
and modify the presented values. Basic validation can be performed and reported.

Eventually, the User will issue either an “Ok” or “Cancel”. With an “Ok”, the new
data is gathered from the Dialog through a get_content method returning the
same trivial representation. The client code will then process this
information appropriately. If the User issues a “Cancel”, the gathered information
is simply discarded.

Testability of the Data Dialog itself is potentially complex due to its synchronous nature.
Client code however can replace Data Dialog with a mock honoring the same interface,
resulting in easier testability of this part of the application.

Practical Example

The following example with Qt will show the main concept outlining Data Dialog.
Both idiomatic python and Qt have been ignored to favor clarity, as usual.

The DataDialog class implements a Dialog with textual fields, an Ok and Cancel buttons.

  1. class DataDialog(QDialog):
  2. def __init__(self, parent=None, flags=0):
  3. super(DataDialog, self).__init__(parent, flags)
  4. self._line_edits = {}
  5. self._data_fields = ["name", "surname", "age"]
  6. layout = QGridLayout()
  7. for row, field in enumerate(self._data_fields):
  8. layout.addWidget(QLabel(field), row, 0)
  9. line_edit = QLineEdit()
  10. layout.addWidget(line_edit, row, 1)
  11. self._line_edits[field] = line_edit
  12. ok = QPushButton("Ok")
  13. cancel = QPushButton("Cancel")
  14. self.connect(ok, SIGNAL("clicked()"), self.accept)
  15. self.connect(cancel, SIGNAL("clicked()"), self.reject)
  16. layout.addWidget(cancel, len(self._data_fields), 0)
  17. layout.addWidget(ok, len(self._data_fields), 1)
  18. self.setLayout(layout)

The core of the design resides in the set_content/get_content pair:
set_content accepts a dictionary with appropriate data for the dialog
fields, and fills the widgets with its contents. get_content retrieves
the data from the widgets and returns them as a dictionary to the client code.

  1. class DataDialog(QDialog):
  2. # <...>
  3. def set_content(self, data):
  4. for field in self._data_fields:
  5. line_edit = self._line_edits[field]
  6. if field in data:
  7. line_edit.setText(data[field])
  8. def get_content(self):
  9. data = {}
  10. for field in self._data_fields:
  11. line_edit = self._line_edits[field]
  12. data[field] = line_edit.text()
  13. return data

The client code interacts with the dialog by setting and retrieving the
data through these two methods:

  1. data = {"name": "Albert",
  2. "surname": "Einstein",
  3. }
  4. data_dialog = DataDialog()
  5. data_dialog.set_content(data)
  6. if data_dialog.exec_() == QDialog.Accepted:
  7. print("Dialog Accepted. Content:")
  8. print(data_dialog.get_content())
  9. else:
  10. print("Dialog Canceled.")