1. ui (user interface)
- console or gui
- It is the entry point and controls everything
- Sees only the API of the structure module
- It is now only the sheet for the moment, but will become a book tree:
BookTree --1*-- BookTreeNode --1*-- Book --1*-- Sheet --1*-- Item --1*-
- It is the only API for the user interface.
- uses a plugin system to add item types to the system, so that
the structure does not know the list of available item types
- it is a minimum data element that can be executed
- examples: table of definition of data, plantrisk execution launcher, etc.
- it is containts one or more elements
- blocks on which the items are based: tables, text, output window
- the ui knows about the elements but not about the items. Each element
corresponds (more or less ?) to a widget.
- code allowing data to be reused from one execution to another
To be added: 6. data model
| | |
V | |
element | |
? | |
V V V
- Each element has as basic flags:
- Each item can have several editable elements, but only one executable element.
- All persistence should stay out of the ui code.
- when editing the ui gets a new value and passes it to the sheet -> item
Hesitation: does the item persist the values or the elements?
--> Both: the elements persists the elements defining its state (a single
element in this case) and the items persists additional information
needed, such as failed, cancelled,
--> NO, to complex! for the moment the item will do everything!
Hesitation: The element class Subprocess should have self.cmd or not?
- pro: it is the attribute needed to run the process. How could the ui
know it otherwise?
- con: the element should have only self.value.
---> Solution: subprocess will have get_cmd!
Division of tasks
ui: controls the
- display (very different if gui or console)
- edition, calling a method in sheet when an element is edited
- execution of the executable elements, calling a method in sheet when the
element is executed.
sheet: contains the logic of
- the script: sequence of executable steps
- the cursor (updated after each execution, depending on the failure etc)
- impact of edition on the cursor.
item (normally defined as a plugin):
- definition: an atomic executable step
- controls the logic of the edition and execution and all the persistance
related to the item and its elements
- defintion: component of the item, known by the ui (the ui has to know
about all items, how to display/edit them and execute, if it is the case
- does it control the persistence of the single element it contains?
- proposal 1: YES, but the method is explicitly called by the item
- proposal 2: NO, it is simpler to let all the persistence to the item (it
has to control the persistence of many things anyway)