At the moment a Fig listens to and updates a single owner model
element. It would also (or instead) have to listen to and update an
owner MDR diagram element. Some work to do but simple enough I should
think.
Once that's in place we can then look at garbage collecting GEF Figs
and Diagrams when they're not in view. Again, there will be some work
to do but I can't see its a major issue.
First step is to build the MDR diagram model and define the facade in
our model subsystem.
I assume your reasons for raising this is to move diagram persistence to XMI.
Could you clarify what you're thinking here -
Do you want to do this before UML2?
If so I assume you're suggesting seperate XMI embedded in zargo/uml.
Or are you suggesting one single XMI for UML1.4 model and diagrams?
Bob.
On 17/12/06, Linus Tolke <[EMAIL PROTECTED]> wrote:
Hello Bob!
You have immediately identified one of the problems that we must keep in
mind in this.
On the other hand, by thinking that there is an intermediate layer, the
"information about the diagram"-layer, we notice that:
* Figs are a lot simpler.
* We can save the model including the diagrams without having Figs
created.
* We can do these modifications to the model for not-created diagrams
without the Figs being notified because there are no Figs.
This is a big refactoring separating the two responsibilities of the
Figs. The gains are that we could use MDR for storing the diagrams
giving us the XMI readers and writers and that the editing part can
focus entirely on usability and functionality. I consider this applying
the MVC pattern on our diagrams.
/Linus
> -----Original Message-----
> From: Bob Tarling [mailto:[EMAIL PROTECTED]
> Sent: den 16 december 2006 21:56
> To: [email protected]
> Subject: Re: [argouml-dev] Idea of a mental image for the Diagrams
> subsystem
>
> > When pondering about saving memory I was thinking that it would be
nice
> if
> > we just have the current diagram (or diagrams) rendered and not all
of
> them.
> > This would mean that when switching to a new diagram, the
information
> about
> > the diagram (position and color of figures...) is restored from
wherever
> and
> > the Figs, Editors etc. are created. The switched from diagram will
> > eventually be garbage collected.
>
> There has been an attempt to do something similar in the past which
> which caused nothing but problems.
> That was not actually deleting the Figs but was dropping the listeners
> of those figs to their owner model element.
> This ended up causing all sort of problems as Figs not on the current
> diagram were not deleted when the model element was deleted and so a
> whole stream of persistence problems.
> I'd say steer clear of complicating the code to do anything like this
> for some time. Lets continue with bugs and implementing required
> functionality.
>
> Bob.
>
> ---------------------------------------------------------------------
> 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]
