About hiding the new interface XRecovery for FormDocument

[Yan Wu-5]

Hi,

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?

Thank you in advance!
Regards,
Yan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

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.


However, let me ask an important question: Why do you really want to
disable this interface?

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.

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.
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.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Yan Wu-5]

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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Yan,

just yesterday Andreas explained the concept to me, again :)

In my previous answers, I assumed that the recovery service would
iterate over all documents registered at the desktop, and use their
XRecovery interface. However, as Andreas reminded me, the plan is that
the recovery services is just a listener at the GlobalEventBroadcaster,
and iterates over all documents known there.

In this case, it is in fact necessary to hide the XRecovery interface
for embedded documents, so please go ahead with this change.

>> 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?

No, I just meant that at some point in its own emergency save process,
the form document needs to emergency-save a certain sub document. If
this document had the XRecocery interface, this would be just a matter
of delegating to this interface.

Now when the sub document does not have this interface, then the form
document needs to decide itself what "emergency save" means for the sub
document. At the moment, this decision is still easy: It's just a simple
"XStorage::storeTo" call.

However, there might be points in the future where the implementation of
XRecovery::store (or however you named it) for text documents is
*extended* to be more than a simple "storeTo". In such a case, we would
need to duplicate this extended semantics in form documents, too. In
case XRecovery were still present at the sub documents, this duplicate
would not be necessary.

That said, I am still a little bit unsure whether hiding the XRecovery
interface is the most future-proof solution, but I think you can go
ahead with it.

Ciao
Frank


--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Yan Wu-5]

Hi Frank,

Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Yan,
>
> just yesterday Andreas explained the concept to me, again :)
>
> In my previous answers, I assumed that the recovery service would
> iterate over all documents registered at the desktop, and use their
> XRecovery interface. However, as Andreas reminded me, the plan is that
> the recovery services is just a listener at the GlobalEventBroadcaster,
> and iterates over all documents known there.
>
> In this case, it is in fact necessary to hide the XRecovery interface
> for embedded documents, so please go ahead with this change.
>
>
>>> 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?
>
> No, I just meant that at some point in its own emergency save process,
> the form document needs to emergency-save a certain sub document. If
> this document had the XRecocery interface, this would be just a matter
> of delegating to this interface.
>
> Now when the sub document does not have this interface, then the form
> document needs to decide itself what "emergency save" means for the sub
> document. At the moment, this decision is still easy: It's just a simple
> "XStorage::storeTo" call.
>
> However, there might be points in the future where the implementation of
> XRecovery::store (or however you named it) for text documents is
> *extended* to be more than a simple "storeTo". In such a case, we would
> need to duplicate this extended semantics in form documents, too. In
> case XRecovery were still present at the sub documents, this duplicate
> would not be necessary.
>
> That said, I am still a little bit unsure whether hiding the XRecovery
> interface is the most future-proof solution, but I think you can go
> ahead with it.
>

Thanks. OK, I will post my questions here when getting problems.:-)

> Ciao
> Frank
>
>
Regards
Yan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hello Yan,

> A new interface com.sun.star.frame.XRecovery is being designed.

I still have issue 65597 (¨Recovery of forms doesn't work as expected¨)
hanging around in my issue list. Fixing this issue would require exactly
such an interface which you started with.

May I ask whether you continued with this work?

Thanks & Ciao
Frank

--
- Frank Schönheit, Software Engineer          frank.schoenheit@... -
- Sun Microsystems                       http://www.sun.com/staroffice -
- OpenOffice.org Base                        http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  -
- Sitz der Gesellschaft:                                               -
- Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten  -
- Amtsgericht München: HRB 161028                                      -
- Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel      -
- Vorsitzender des Aufsichtsrates: Martin Häring                       -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...