Remove SessionItem-related methods and mechanism from JobItem (Major change)
All SessionItem
-related mechanism and data-structures are removed from JobItem
.
The following 'children tags' (SessionItemTags
) are replaced by their simpler explicit equivalents:
* P_IDENTIFIER => QString
* P_INSTRUMENT_NAME => QString
* P_PRESENTATION_TYPE => QString
* P_PROGRESS => int
* P_STATUS => JobStatus
* P_BEGIN_TIME, P_END_TIME => QDateTime
* P_COMMENTS => QString
* T_FIT_SUITE => std::unique_ptr<FitSuiteItem>
* T_DATAVIEW => std::unique_ptr<Data1DViewItem>
* T_OUTPUT => std::unique_ptr<DataItem>
* T_REALDATA => std::unique_ptr<RealDataItem>
* T_DIFF => std::unique_ptr<DataItem>
The following unused SessionItemTags
are removed:
* P_WITH_FITTING
* T_MATERIAL_CONTAINER
The correct initialization method for the new data members (like m_realDataItem
) is found after a detailed runtime debugging via gdb
: Most importantly, each class member of type SessionItem
(like T_REALDATA
) must inherit the model of its parent (here, JobItem
). Furthermore, the SessionItem
destructor which relies on the original mechanism (tree-like hierarchy of SessionItems
) is accordingly amended.
The most difficult problem is the re-implementation of the serialization/deserialization of the class.
The SessionItem
mechanism cannot be used anymore since, after refactoring, the original 'parent-child' relation (tree-like hierarchy of SessionItems
) is broken. Furthermore, since the copying operation of the SessionItem
mechanism is based on this particular serialization method, extra care is needed after the refactoring to avoid data loss, data corruption or unexpected crashes [see this note]. For this purpose, GUI::Session::XML::readItemAndChildItems
and GUI::Session::XML::copyItem
functions is added.
Note that SessionItem
still remains as parent of JobItem
, although the latter is free from the methods of the former. This is required to allow for an iterative refactoring.
In spite of the care taken, due to the runtime polymorphism of the SessionItem
mechanism, bugs might be lurking in the GUI, although all tests pass. Therefore, a comprehensive testing of the GUI is still necessary.
Related to issues #89 (closed), #90 (closed)