Hello Bob!
I am very glad to see this kind of discussions on the dev list. I will just
add some small ideas.
You say "a system with say 3000 FigAttributes". I would prefer if we would
say "a Diagram with say 3000 FigAttributes" to start thinking that we don't
really need to have Fig objects, Notation objects, etc. created and
receiving events for not showing Diagrams. They could be created when that
Diagram is selected for display and forgotten about and collected by the
garbage collector, when the Diagram is no longer displayed.
The Observer, Publisher-Subscriber, or PropertyChangeEvents are the natural
patterns to use for this. To allow the Garbage collector to collect the
Notation objects when dropping diagrams, erasing models, etc., some
special considerations are required. I notice that there is already a lot of
code handling the removal (removeFromDiagramImpl(), and
notationProvide.cleanListener(...)) so this is probably solved in another
way.
Why would MDR and eUML have different Notations? It would probably rather be
that cpp, csharp, idl, java, had different notations without being aware of
the different model implementations.
/Linus
2008/5/16, Bob Tarling <[EMAIL PROTECTED]>:
>
> First off I'd like to hold my hands up here and confess that the
> design of the Notation subsystem is based on some pressure from
> myself. Issue 1207 shows some history of this, look for this first
> entry by Daniele Tamino.
>
> My concern when supporting this was that for a system with say 3000
> FigAttributes that we weren't needlessly creating another 3000
> notation objects for each attribute. My hope was that using a
> flyweight factory we could return the same instance of a Notation for
> all FigAttributes. Similar for operations, model element names and
> anything else representing a model element as text.
>
> What I didn't appreciate was the complexity that would be added by the
> notation instructing the Fig of what to listen to and the fig then
> calling the notation based on that info.
>
> I'd like to suggest we reconsider this (Michiel will most likely want
> to string me up as a fair bit of this is I think as at least the first
> part of this is his original intention).
>
> What I would like to see is a one to one (unidirectional) relationship
> between each FigText and a Notation. The FixText itself should not be
> listening to change on the model element, nor should
> FigNodeModelElement or any of its subclasses.
>
> What I would suggest is that the Notation class itself listens to
> model element changes and on recipt determines its notation text. The
> Notation then fires a NotationTextChange event to which the FigText is
> listening for.
>
> The FigText should just update itself with text data received in the
> event, it should not need any knowledge of the model element itself.
> Only if this results in it's increasing in size so that it is wider
> then it container Fig should it then call its containing Fig to
> intruct it to resize. That container Fig should then
> resize itself and again call its parent if its bounds have grown too wide.
>
> The only Figs that should be listening for model events would be those
> that represent a composite model element structure. For example the
> container of
> operations and attributes shown in a class. It should still not be the
> top level FigClass listening to the model though. Rather it should be
> some specialist child Fig contined inside, for FigClass that would be
> FigOperationsCompartment listening for add and remove of operations
> and FigAttributesCompartment listening for add and remove of
> attributes.
>
> The tree below shows * for those FigText classes that should listen to
> Notation and ! for compartments that should listen for add/remove of
> very specific elements in model.
>
>
> FigClass contains
> |
> |-FigNameWithAbstractAndBold *
> |
> |-FigStereotypesCompartment !
> | |-FigStereotype *
> | |-FigStereotype *
> |
> |-FigOperationsCompartment !
> | |-FigOperation *
> | |-FigOperation *
> |
> |- FigAttributesCompartment !
> |- FigAttribute *
> |- FigAttribute *
>
>
> So FigClass itself should have no need to listen to model events
> although FigNodeModelElement will still have code to remove the Fig on
> a delete event.
>
> This takes away the mass removal and addition of events at the top
> level of Fig whenever there is some change in the model and also the
> frequent restructuring of Figs that often seems to take place at that
> level.
>
> What can we do to start moving towards this structure? The notation
> classes seem to be the place to start? The mistakes there are partly
> my fault, so how can I help to set it right.
>
> Maybe this is not so important right now with other defects around.
> Could it be something to consider for a GSOC next year?
>
> I'm also wondering if a NotationFactory instance should be provided
> via our model interface. That would allow the UML2 notations to be
> provided from eUML and our existing notations to be provided from MDR
> with no place in the rest of application aware of the difference.
>
> At the moment I understand that not all Figs use notations and some
> still build their own. I think use of notations for diagrams should
> become mandatory.
>
> Apart from making it clearer what the Figs need to listen to and
> having them updated less frequently it takes some logic out of the
> diagram that could be reused when moving from tigris GEF to eclipse.
>
> Bob.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
