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]
