Re: [dba-dev] About hiding the new interface XRecovery for FormDocument
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-unsubscr...@dba.openoffice.org For additional commands, e-mail: dev-h...@dba.openoffice.org
Re: [dba-dev] About hiding the new interface XRecovery for FormDocument
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=EmbeddedScriptSupportdefs=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_SCRIPTSproject=/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
Re: [dba-dev] About hiding the new interface XRecovery for FormDocument
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=EmbeddedScriptSupportdefs=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_SCRIPTSproject=/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.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org For additional commands, e-mail: dev-h...@dba.openoffice.org
[dba-dev] About hiding the new interface XRecovery for FormDocument
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-unsubscr...@dba.openoffice.org For additional commands, e-mail: dev-h...@dba.openoffice.org
