Hi Daniel,
On 02/20/09 02:49, Daniel Brosseau wrote:
Hi Mikhail, Frank,
Thank you again.
since it would allow returning more information (and thus
would have saved you the question, since you would have got a
message saying "not allowed for this implementation").
As an extreemly minor point:
I got a return of "false" and not "not allowed for this implementation" :)
I have tried loading at the Frame level. I get the Frame
by first loading a _blank component from the Desktop's
XComponentLoader and then moving up from the XComponent's
XModel to the XController to the XFrame. I then get the
XFrame's XComponentLoader to load subsequent URL's into the Frame.
The load replaces the previous Model but does not close it
This is a bug. I have just written a small basic script to test this,
and indeed in case a document is loaded as hidden one, the controller
does not close the model. In case of visible documents it works well,
the model is closed.
Could you please write a bug to me.
so I close the previous Model after the Frame is loaded with the new URL.
If I do not close the previous Model, the memory usage in soffice.bin
increases continuously with each load.
Yes, a model has to be closed to end the objects lifetime. This is
designed so, because the complex system of objects let cycle
dependencies appear. And since the controller erroneously does not try
to close it in this case, it stays open.
In these circumstances your workaround to close the model after it is
replaced in the frame is absolutely correct. After the mentioned above
bug is fixed it will not be necessary any more.
You can implement the workaround so that it is ready for
DisposedException. If controller closes the model after the fix, the
next try to close it will throw the exception ).
This scheme is definitely much
more stable than anything I tries before. Thanks :)
Glad that it helps :)
If I close the old XModel before the load of the new URL I destroy the
whole Model-Controller-Frame structure.
It is designed so. When a model of a frame is explicitly closed, it
means that the document is closed. Since the model is still attached to
the structure, the whole structure is closed.
From other side if the frame is closed it disposes the controller. And
the controller should close the related model if it is the last view of
the document.
I have tried to use XDesktop.terminate() at the end but this hangs or
crashes so I just dispose the Xdesktop through it's XComponent interface.
That is not correct. To shutdown office per API the terminate() call
should be used. Please see the following link for details.
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Using_the_Desktop
The fact that the call let office crash/hang is a problem. The
developers guide mentiones that modified documents might be a problem in
this case. Please try to set all remaining documents to nonmodified
state before terminating and probably close them.
Please also check that the call is done in the main thread. If not,
please try the workaround to let it be triggered from the main thread
that I have posted yesterday.
Anyway, could you please send the crash when it crashes next time. You
could use crashreporter for this, in this case it would be enough just
to provide the crash ID to allow to find the stack.
When I load a new URL I use the property ( "Asynchron",false ). I am not
certain this is required but I quess (you see I guess too) this uses the
SynchronousFrameLoader service.
Normally the loadComponentFromURL() should be always synchron. So this
call should let the default scenario be used.
Thank you both again,
Daniel
PS
On the question of design, I guess my questions arose because as
a recent re-comer to OpenOffice.org I concluded wrongly from the
general tone of the API and the documentation that the
Frame-Controller-Model paradigm was orthogonal and that each represented
relatively independent blocks that could be manipulated individually.
But I realize that in the implementation, the complexity of the
interactions really has meant that they form a relatively monolithic
block. In fact, in the API that gets commonly used we ask the Frame
to give us a Model (XComponentLoader.loadFromURL()!). Nothing wrong
with this. I was just going with the flow and infering things from the
API and documentation that weren’t there. As long as I understand
and it works, that's great.
At the beginning the API design politic was to create relative universal
and independent interfaces that had to be built together afterwards. As
a result it could lead to conclusion that the implementation is similar
to a Lego set.
Although it would be probably very comfortable for API programmer to
have such independent objects, the practice shows that a gold middle
between monolithic approach and spread independent objects approach has
to be taken.
The framework project has done already big steps to let the objects be
more independent, it is planned to do the refactoring further, although
unfortunately there are not so much resources for this.
Best regards,
Mikhail.
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: February 19, 2009 11:16 AM
To: [email protected]
Subject: Re: [api-dev] How to attach new Model to old Controller
Hi Daniel,
I guess there is a theoretical API and a real api.
Well, as Mikhail said, the API definition allows for
rejecting an attempt to attach a new model.
As a secondary thought, I'd say that a VetoException or
something like this would have been a better API design,
since it would allow returning more information (and thus
would have saved you the question, since you would have got a
message saying "not allowed for this implementation").
I take it then that exchanging models can't be done?
Yes.
However, it would be interesting to know what you want to
achieve with this. Even if replacing a model at an existing
controller would be implemented, there's hardly any aspect of
the controller which would survive this. In other words, the
controller would implicitly need to reset itself to a state
which pretty much equals its state when it's newly created,
and got its very first model.
That said, perhaps Mikhails suggestion to simply load the new
document into the existing frame suits your needs.
Is there a quick way to exchange or replace the contents of a Model
with that of another model?
Try using XLoadable::load a second time. If your Model_B
really exists as model only (and not as file), then store it
to a temporary location beforehand.
In my understanding, XLoadable::load should be reusable,
though I of course do not know whether its implemented this
way everywhere :)
Depending on your application architecture, you need to care
for side effects. E.g. if some of your components caches any
direct or indirect property (in a very broad sense) of the
model, you need to invalidate all those data.
Again, I think evaluating the "load another document into the
same frame" approach is worth an evaluation, to prevent this
kind of problems.
Ciao
Frank
--
- Frank Schönheit, Software Engineer
[email protected] -
- Sun Microsystems
http://www.sun.com/staroffice -
- OpenOffice.org Base
http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
