MantisBT
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0029822Community[OCCT] OCCT:Application Frameworkpublic2018-05-29 03:492018-05-31 03:32
ReporterVico Liang 
Assigned Tompv 
PrioritynormalSeverityminor 
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version 
Target Version[OCCT] 7.4.0*Fixed in Version 
Summary0029822: Make TDocStd_Document extensible
DescriptionDocument creation mechanism is sealed inside the OCAF framework. There is no way or convenient way to subclass TDocStd_Document to cooperate with OCAF. When design application, it's unavoidable to extend class TDocStd_Document.

There are several places create document:
void TDocStd_Application::NewDocument(const TCollection_ExtendedString& format,Handle(TDocStd_Document)& aDoc)
Handle(CDM_Document) BinLDrivers_DocumentRetrievalDriver::CreateDocument()
Handle(CDM_Document) XmlLDrivers_DocumentRetrievalDriver::CreateDocument()

It would be more convenient if the NewDocument method is center controlled inside TDocStd_Application, so we can override the document creation method in one place.
TagsNo tags attached.
Test case number
Attached Files

- Relationships

-  Notes
(0076409)
mpv (developer)
2018-05-29 16:28

We don't expect or advise the developer extends TDocStd_Document. It is a data container that provides standard (and generic) methods for working with data, suitable for any application.

If you want to implement application-specific interfaces to the document, you simply may create a new interface-class that whould keep the TDocStd_Document as a field. One of the advantages here is that this higher-level interface does not provide an access low-level methods of Document to the user of this object.
(0076423)
Vico Liang (developer)
2018-05-30 04:41

>We don't expect or advise the developer extends TDocStd_Document.
I don't think we should limit the user to do so. It's no any problem for user to extend TDocStd_Document as long as there is single entrance to create user defined Document. Another problem is that there are several entrance to create document, it's hard to maintain the consistence.

I suggest to remove the these two document creation methods:
Handle(CDM_Document) BinLDrivers_DocumentRetrievalDriver::CreateDocument();
Handle(CDM_Document) XmlLDrivers_DocumentRetrievalDriver::CreateDocument();

And add a virtual method as below:
Handle(CDM_Document) TDocStd_Application::NewDocument();

With this minor changes, will make the interface simpler and maintainable and also user can extend document class by just override this method in application.
(0076437)
mpv (developer)
2018-05-30 14:32

CreateDocument are virtual methods. If they are removed, we lose possibility for custom schema (thar inherits retriveal drivers) to create document in a specific way.

Actually, this is not as simple as you wrote because of dependencies and current usage of this mechanism. I would ask you to prepare an OCCT patch that is good for your application and then we will decide is this approach usefull in OCCT as a standard behavior.
(0076441)
Vico Liang (developer)
2018-05-30 16:28

> CreateDocument are virtual methods. If they are removed,
> we lose possibility for >custom schema (thar inherits retriveal drivers)
> to create document in a specific way.
It will cause mismatching if the document type created in retrieval drivers is different from the document type in TDocStd_Application::NewDocument() method. For an application, it should make sure that all document created are the same type including the retrieval driver. That's to say, the storage driver and the retrieval driver should use the same document type.
(0076442)
Vico Liang (developer)
2018-05-30 16:40

I searched the whole source code tree there is not a case redefined method CreateDocument() in retrieval drivers, all use class TDocStd_Document. It should not be a problem to upgrade user's program with such changes.
(0076444)
mpv (developer)
2018-05-30 16:57
edited on: 2018-05-30 16:57

"to create document in a specific way" is not the same as creation of new type of the document. There could be new attributes added, some labels structure prepared, etc.

The custom way of document creation is out of the OCCT scope this is an application-specific functionality.

(0076445)
Vico Liang (developer)
2018-05-30 17:07

but you can't imagine that user won't define a new document type.
(0076446)
Vico Liang (developer)
2018-05-30 17:11

A good mechanism will prevent user making mistake and guide them in the right direction.
(0076448)
mpv (developer)
2018-05-30 17:36

What is the added value from a new document type? There are different ways to change content of the document (like creation of new kinds of attributes). Normally application-specific data is stored inside using standard atomic types. Here the specific part is the specific combination of these attributes. Attributes are standard, but the meaning for different applications is different.

It is like you are asking for inheriting "int" type in C++. You may create a specific-meaning interfaces only by keeing "int" in the field of this interface.
(0076455)
Vico Liang (developer)
2018-05-30 19:10

I consider more about the document creation mechanism. It's easy to confuse user with several document creation entrances. It would be more simpler and better understanding for developer with single document creation entrance. We can provide a method Init(Handle(TDocStd_Document& theDoc) in retrieval drivers to replace the CreateDocument() method. So with these changes, the document creation should be always the same type.

It sometimes make sense to inheriting document type with several other temp field instead of standard attribute. Anyway, Document is a rather big class, user have his own decision to inheriting it by adding more application specific logic inside it base on base class implementation.

- Issue History
Date Modified Username Field Change
2018-05-29 03:49 Vico Liang New Issue
2018-05-29 03:49 Vico Liang Assigned To => mpv
2018-05-29 16:28 mpv Note Added: 0076409
2018-05-29 16:28 mpv Assigned To mpv => Vico Liang
2018-05-29 16:28 mpv Status new => feedback
2018-05-30 04:23 Vico Liang Note Added: 0076422
2018-05-30 04:24 Vico Liang Assigned To Vico Liang => bugmaster
2018-05-30 04:26 Vico Liang Note Deleted: 0076422
2018-05-30 04:41 Vico Liang Note Added: 0076423
2018-05-30 04:44 Vico Liang Assigned To bugmaster => mpv
2018-05-30 04:44 Vico Liang Status feedback => assigned
2018-05-30 14:32 mpv Note Added: 0076437
2018-05-30 14:33 mpv Assigned To mpv => Vico Liang
2018-05-30 14:33 mpv Status assigned => feedback
2018-05-30 16:28 Vico Liang Note Added: 0076441
2018-05-30 16:40 Vico Liang Note Added: 0076442
2018-05-30 16:57 mpv Note Added: 0076444
2018-05-30 16:57 mpv Note Edited: 0076444 View Revisions
2018-05-30 17:07 Vico Liang Note Added: 0076445
2018-05-30 17:11 Vico Liang Note Added: 0076446
2018-05-30 17:36 mpv Note Added: 0076448
2018-05-30 19:10 Vico Liang Note Added: 0076455
2018-05-31 03:32 Vico Liang Assigned To Vico Liang => mpv
2018-05-31 03:32 Vico Liang Status feedback => assigned


Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker