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 werent 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]
