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 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. This scheme is definitely much more stable than anything I tries before. Thanks :) If I close the old XModel before the load of the new URL I destroy the whole Model-Controller-Frame structure. 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. 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. 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. > -----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]
