Hi All,
Since my last mail, I have been attempting to work out what I described.
This lead to some problems:
I did not find an elegant way to remove listeners, and adapt when the
model changes.
This would have lead to expansion of an interface between subsystems so
that it became clear that the division of the work between the
subsystems was wrong.
Hence, I changed the design again. A preliminary patch according this
architecture is attached to issue 1207.
This solution is closer to my original idea to have the
NotationProviders listen to model changes, and I feel more happy with
this solution so far.
In short, the NotationProvider is now listening to the modelchanges, and
updating its own set of model-listeners when required.
And, I replaced the former NotationProvider4 interface by a (new)
NotationProvider class, that implements the java.util.Observable class.
This allows the Fig to create a simple small java.util.Observer class,
that updates the text on the diagram.
Hence the class inheritence is now:
java.util.Observable - NotationProvider - AssociationEndNameNotation -
AssociationEndNameNotationUml.
I will give it some more thought before committing.
Any remark welcome.
Regards,
Michiel
Michiel van der Wulp wrote:
> Hi All,
>
> I have a new proposal for the way that the notation providers can listen
> to model changes (different from the way proposed in the latest cookbook).
>
> This change is needed to
> 1. Simplify the Figs,
> 2. Since with different languages (UML, Java, C#,...) it may become
> necessary to listen to different model change events.
> 3. Currently the knowledge of which modelelements and events are needed
> to build a notation string is distributed over the Fig and the
> NotationProvider.
>
> The proposal:
>
> 1. The Fig listens to model change events as currently.
>
> 2. The Fig delegates the registering of events to the notation provider
> by calling (in the initNotationProviders function):
> NotationProvider4.registerListeners(PropertyChangelistener this);
>
> 3. When the model changes, and the Fig gets a PropertyChangeEvent, it
> delegates the reaction on the event to the Notation provider as follows:
> if (NotationProvider4.propertyChanged(PropertyChangeEvent pce)){
> setText(notationProvider.toString());
> }
> Hence, the NotationProvider4 shall also have a method:
> boolean propertyChanged(PropertyChangeEvent);
> which returns true if the string needs updation, and false if not.
>
> Please give your opinion about this architecture!
>
> BTW: Is this not a known pattern?
>
> Regards,
> Michiel
>
> ---------------------------------------------------------------------
> 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]
