Hi Daniel,
It is possible that a model has more than one view. That makes the
controller implementation that let the model be closed relative complex.
So in case of hidden document the controller does not do behave itself
as expected, that it a bug.
I would not accept this bug as a feature, since it is a quite
unpredictable behavior that let the design look somehow inconsistent.
According to the current design the owner of the model should close it,
and in this scenario the controller is the owner. If somebody wants to
let the model stay alive he can just register a close-listener and
prevent model closing.
So I would kindly ask to open a bug for this.
Thanks,
Mikhail.
On 02/23/09 20:42, Daniel Brosseau wrote:
Hi Mikhail,
Thank you for your explanations.
With regards to the Controller not closing the Model on loadTromUrl,
I would rather the bug stay in because the workaround is very easy and
I do not know how you would keep a Model alive and detach it from its
Controller if you could not do it this way. It is a step towards
orthogonality. Unless the Frame creates both a Controller and a Model
on loadFromUrl and just Closing the Model after the load keeps a
Controller in limbo somewhere, there is no harm done by
having to dispose the replaced Model afterwards, but it opens the door
to greater flexibility.
Regards,
Daniel
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: February 20, 2009 4:58 AM
To: [email protected]
Subject: Re: [api-dev] How to attach new Model to old Controller
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/DevGuid
e/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]
---------------------------------------------------------------------
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]
