Hello Bob!
You raise some other interesting points here.
First off, my immediate reaction is that the Fig in this case will only
listen to and update according to the owner MDR diagram element. To
explain this, I would like to be able to use the MVC pattern
explanation. Alas, there is one item of the MVC that I have never really
understood that is exactly this part. I will try:
MDR diagram element - Model
Fig - View
??? - Control
Where is the Control-part in this? If it is in the Fig, then indeed it
has to listen to the owner model element. If it is in some layer below,
then that layer will have to implement much of the UML logic (that will
then be moved from the current Figs), and if it is somewhere else, then
where.
The XMI and persistence issue is one reason for raising this. Something
needs to be done here.
I have no clear view of when this can be done. I think that this will
take us closer to UML2 i.e. that it will be one of the refactorings that
will take us there. Perhaps it would be a good idea to work to isolate
the changes needed for UML2 to just two of the three MVC-layers and let
that govern our architectural choices.
/Linus
> -----Original Message-----
> From: Bob Tarling [mailto:[EMAIL PROTECTED]
> Sent: den 17 december 2006 14:49
> To: [email protected]
> Subject: Re: [argouml-dev] Idea of a mental image for the Diagrams
> subsystem
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
