Hi Frank,
Frank Schönheit - Sun Microsystems Germany wrote:
Hello Yan,
A new interface com.sun.star.frame.XRecovery is being designed. It will
be used by the autorecovery service inside the framework module and
supported by all applications. FormDocument of database, which is not
used as a top level document, will ignore the new interface.
Currently, ODatabaseDocument can inherit XRecovery and implement its
method load/save. I want to pass some parameters, which can disable the
interface XRecovery, to the sw::ctor() when creating a new FormDocument.
I tried to do this in the ODocumentDefinition::loadEmbeddedObject(...)
but found no good way. How can I pass some parameters to the sw::ctor()
when creating a new FormDocument in database?
There already is a mechanism for passing parameters to the document
implementation, to disable certain functionality.
For instance, for the documents embedded in a database document, we
disable the usage of XEmbeddedScripts.
For this, we pass a parameter "EmbeddedScriptSupport" when creating the
document, see
http://svn.services.openoffice.org/opengrok/search?q=EmbeddedScriptSupport&defs=&refs=&path=&hist=&project=%2FDEV300_m40.
In SFX, this creation parameter is translated into the
SFXMODEL_DISABLE_EMBEDDED_SCRIPTS flag, which is passed to the document
factory:
http://svn.services.openoffice.org/opengrok/xref/DEV300_m40/sfx2/source/doc/sfxmodelfactory.cxx#176
Then, the factories for the various document types examine the presence
of this flag
(http://svn.services.openoffice.org/opengrok/s?refs=SFXMODEL_DISABLE_EMBEDDED_SCRIPTS&project=/DEV300_m40),
and translate it into a call to SfxObjectShell::SetHasNoBasic:
http://svn.services.openoffice.org/opengrok/xref/DEV300_m40/sw/source/ui/app/docshini.cxx#401
This, finally, instructs the SfxBaseModel belonging to the
SfxObjectShell to *not* expose the XEmbeddedScripts interface.
Thanks for your explanation for this mechanism. I think I can refer it
if XRecovery really needs to be hidden.
However, let me ask an important question: Why do you really want to
disable this interface?
Considering a FormDocument will be saved twice - saved explicitly as sub
contents , and saved implicitly as a writer document.
First, it should not hurt if it is present: The auto recovery process
iterates over all documents which are known at the desktop, and "sub
documents" of a database document are explicitly *not* known at the desktop.
The sub documents will be ignored further though if it supports
XRecovery, so there is no need to hide this interface for the current
autorecovery code. It seems that I missed it here.
Second, the non-presence of this interface would make the implementation
in Base harder: To properly implement a emergency-save and auto-recovery
for Base documents, we also need to emergency-save and auto-recover the
sub documents.
For instance, when you have a database document and one form open, and
OOo crashes, then Base needs to save both the database document, *and*
the form. The latter is done easiest, if course, if it can be delegated
to the form itself.
If form(sub documents) can call storeToStorage in the autorecovery
service, it will become easy.
So, the save-code in Base would look like
- create a wrapper storage
- save my own content
- create a sub storage for every opened form
- use the form's XRecovery to save it into the sub storage
So, the bottom line is: When you remove the XRecovery from embedded
forms, this will make final implementations more difficult.
Does it mean making database document store it's own sub documents is
difficult?
Ciao
Frank
Regards
Yan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org
For additional commands, e-mail: dev-h...@dba.openoffice.org
