What are the views on being able to adapt the existing notation subsystem to this - http://argouml.tigris.org/wiki/Ideas_for_GSoC_2010?highlight=(gsoc)#head-ac01ae73d64fa48b2d48a627b74f4f56e05403e1
As an example I'll try to describe the current pattern and the pattern I'm hoping we can get to At the moment when we have multiple FigOperations each one of those uses the same single instance of an OperationNotation to ask that notation what model elements the Fig should listen to. Each of those Figs then adds a listener to all the model elements involved (ie the operation model element, the elements for each parameter and each stereotype). Each time the Fig detects a change it calls the notation again asking how to draw itself. It also then has to call the notation again to ask what to listen to once more as the change could have been removal or addition of a parameter to the operation. This results in tow problem 1. Listeners are dropped and then re-attached 2. It can result in multiple redraws as often the name and multiple parameters could have changed in quick succession if the user edited on the diagram. With our current architecture that can even result in redrawing the whole compartment or FigNode multiple times. If we can change this so that we have one OperationNotation instance created for each OperationFig we get the benefit that the OperationNotation itself can register to and listen for all the changes required. When a notation detects a change it can then fire an event that the Fig is listening for. That event contains the actual new notation string so there is no need for the Fig to call the notation to ask what to display. There is also no need for the Fig to drop any listeners and reapply them so there is never any event lost. The notation could be run in another thread. If it has a slight delay before sending an event to the Fig it could detect multiple changes from parts of the model but send only one event to the Fig. We immediately get less Fig redraws. Once this is in I think it will make the Figs easier to adapt so that a single event does not result in the whole FigNode being redrawn as can happen now. One of the reasons I think a complete redraw happens is if a change to the model happens such as changing an operation name so that it is wider than the current compartment it sits in. The easiest way to fix that is just to redraw the whole FigNode and at the moment because the code is so complex the easiest is what happens. What I would like instead is that the FigNode will only have to listen for delete events from the model. The FigSingleLineText only listens for notation events when it receives one it redraws itself only and fires a resize event if required. The FigCompartment the FigSingleLine edit is inside is listening for its childrens resize events. If it gets one it resizes itself if required and fires its own resize event. The FigNode containing compartments also listen for resize events from them and resizes itself if it needs to. This all seems to me to be simple and elegant. All of this hinges on the notation subsystem changing though. I'm querying this now as I'm creating a brand new diagram and Figs for the activity diagram. I'm wondering if its worth my making the effort of creating notations in the current style and is anyone ever likely to do the work I suggested above after. To rework all the notation subsystem now would mean a massive change to all the Figs in one hit. Would it be better to create a parallel notation subsystem now with a slightly different architecture. Start of using that and migrate the other diagrams to use that later. FigNodeModelElement could be adapted to use the existing notation subsystem by default but an alternative one based on some boolean flag. We can then migrate Fig at a time when ready. Regards Bob ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2634120 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
