MantisBT - Open CASCADE
View Issue Details
0030773Open CASCADE[OCCT] OCCT:Application Frameworkpublic2019-06-06 18:102019-06-19 10:37
[OCCT] 7.3.0 
0030773: Application Framework - To allow to inherit existing attributes to reuse persistence mechanisms
Currently most of the medium and big size-applications that use OCAF data structures covers them by higher-level interfaces. They allow involving application-specific names, relations between data, some simple logic over the basis OCAF components.

For an example: there may be “Color” class that covers the array of integer attribute (RGB). It manages OCAF data by reference to attribute of to the label. It may:
• Provide application-specific access to the data: methods ”blue”, “setBlue”, “isWhite”, etc.
• Support references between objects. Like, this label may contain not array attribute, but reference to other array or object or pointer to external, not OCAF object. Method “blue” and others may correctly manage this.
• To cash some data based on persistent values to avoid too often computation. Like “intensity” by RGB.

Disadvantage of such approach is that the interface classes hardly can be persistent. Normally interface is created on the fly by demand and cannot live longer than a transaction. This approach does not allow the cashing, keeping some objects in fields and controlling the data modification.

If objects are more persistent, there appeared a problem with update of these objects on undo/redo, abort and load/save operations. Modification of OCAF data may be done outside of related objects, so it breaks the object-oriented approach and an idea of encapsulation.

Currently here appeared a problem that it is required to create interface-objects by some data of TDF_Attribute. Low level OCAF entities (labels and/or attributes) in many cases become arguments of methods for creation, searching or iteration of high-level interfaces. It is necessary anyway to create some kind of factory that creates interface-objects (at least on load of the document) by the presented OCAF structure. Another approach may be to inherit the OCAF attributes and somehow control the data change (AfterUndo and other similar methods), but this requires complicated development to implement persistent mechanism for them (in general, at least for 2 standard formats supported) and other things. With the current way of implementation it is simple code-duplication.

In this improvement it is proposed to allow developer to inherit existing attributes if the same persistent fileds are used. All methods that allow controlling the data model changes or getting some callbacks may be overridden in successor.
Development of persistence mechanism for such attributes is minimal. In the example above for “Color” class it will be enough to inherit “TDataStd_IntegerArray”, so, functionality of “TDataStd_IntegerArray” will be used to store/restore all the needed data. Minimal requirement is to redefine NewEmpty method (ID and GetID to have different GUID, other methods for more complicated behavior).

To re-create such attributes on load of the file, there must be a special factory. It is proposed to add it to the TDF_Attribute.hxx file, so, no additional includes will be required to make a derived attribute. A special macro will register a new derived attributes in the factory (it may be callled instead of standard Handle macro definition: IMPLEMENT_STANDARD_RTTIEXT).

The main benefit for OCCT is that derived attributes contain only interfaces and new GUIDs (and dynamic type) and require no classes in persistent drivers (like TDataStd_Comment may inherit TDataStd_Name and the following drivers become obsolete: BinMDataStd_CommentDriver, XmlMDataStd_CommentDriver, part of StdLPersistent_Value).

This improvement should not change both present formats Bin and XML documents. THe obsolete Standard scheme is not changed at all.
Not required
No tags attached.
Issue History
2019-06-06 18:10mpvNew Issue
2019-06-06 18:10mpvAssigned To => mpv
2019-06-06 18:24gitNote Added: 0084935
2019-06-07 13:44kgvSummaryTo allow to inherit existing attributes to reuse persistence mechanisms => Application Framework - To allow to inherit existing attributes to reuse persistence mechanisms
2019-06-07 16:28gitNote Added: 0084947
2019-06-11 09:49gitNote Added: 0084981
2019-06-13 10:20mpvNote Added: 0085025
2019-06-13 10:20mpvAssigned Tompv => szy
2019-06-13 10:20mpvStatusnew => resolved
2019-06-13 10:20mpvSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=21351#r21351
2019-06-14 12:46szyNote Added: 0085050
2019-06-14 12:47szyNote Added: 0085051
2019-06-14 12:47szyAssigned Toszy => mpv
2019-06-14 12:47szyStatusresolved => feedback
2019-06-14 15:39gitNote Added: 0085055
2019-06-17 17:14mpvNote Added: 0085093
2019-06-17 17:14mpvAssigned Tompv => szy
2019-06-17 17:14mpvStatusfeedback => resolved
2019-06-19 10:37szyNote Added: 0085138
2019-06-19 10:37szyAssigned Toszy => bugmaster
2019-06-19 10:37szyStatusresolved => reviewed

2019-06-06 18:24   
Branch CR30773 has been created by mpv.

SHA-1: 3468f571674dbc9e876bad577980f70d0465c126

Detailed log of new commits:

Author: mpv
Date: Thu Jun 6 18:23:34 2019 +0300

    30773: To allow to inherit existing attributes to reuse persistence mechanisms
    Added possibility to inherit attributes, supported by Deriver Attributes factory in TDF_Attribute, macros and DerivedDriver instance in the Bin and XML data storage.
    Removed drivers in Bin and XML schemes for derived attributes.
2019-06-07 16:28   
Branch CR30773 has been updated by mpv.

SHA-1: 2540bde130ea87e5a83646fd8c9752066e58c88a

Detailed log of new commits:

Author: mpv
Date: Fri Jun 7 16:28:07 2019 +0300

    30773: To allow to inherit existing attributes to reuse persistence mechanisms
    # Correction of compilation warnings

2019-06-11 09:49   
Branch CR30773_2 has been created by mpv.

SHA-1: 7f21b051d965bea56dfeea4da88cbb08766454d7

Detailed log of new commits:

Author: mpv
Date: Tue Jun 11 09:46:16 2019 +0300

    30773: Application Framework - To allow to inherit existing attributes to reuse persistence mechanisms
2019-06-13 10:20   
Solution is in CR30773_2 branch: many drivers in Bin and Xml persistence schemes are removed due to duplication of functionality of drivers, or fully empty drivers methods.

No regressions are detected:
http://occt-tests/CR30773_2-CR30773_2-MPV-Products/Debian80-64/diff_summary.html [^]
http://occt-tests/CR30773_2-CR30773_2-MPV-OCCT/Windows-64-VC14/diff_summary.html [^]

Please, review.
2019-06-14 12:46   
1.IntegerDriver (Bin & Xml) modification
if (!ok) {
      ok = Standard_True;
    } else ...
It means that expected predefined attribute (before TDataStd_Integer).
Removing line anAtt->SetID(...) is dangerous as it leads to not initialized field.
It should be processed taking into account as parent as derived types.

2.It is not desirable to use static maps (DERIVED & DERIVED_TYPES) as it blocks possibility to use it in multi-threading application.
It would be better to use another solution with dynamic creation. Let's discuss it.
2019-06-14 12:47   
See my comments.
2019-06-14 15:39   
Branch CR30773_2 has been updated by mpv.

SHA-1: 1056ba2343c05ec33814341474943fe6f188032b

Detailed log of new commits:

Author: mpv
Date: Fri Jun 14 15:39:03 2019 +0300

    30773: Application Framework - To allow to inherit existing attributes to reuse persistence mechanisms
    Protection for the multi-threaded open/save of documents with different resources.

2019-06-17 17:14   
It is discussed that the first note is not needed to implement: GUID is defined in the constructor of the attributes.

The second note is fixed in branch CR30773_2 : access to the map is covered by a mutex. [^] [^]

Please, review.
2019-06-19 10:37