Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Graphiti » NotificationService & Updates
NotificationService & Updates [message #757131] Wed, 16 November 2011 11:05 Go to next message
Matteo Miraz is currently offline Matteo Miraz
Messages: 38
Registered: March 2011
Member
Hi,

I have some issues with the notification service.

I have to say that my diagrams only show part of the elements of the model: other elements contribute by decorating shown elements. Let me use an example:

The model class has a list of commands.
There are two types (subclasses) of commands: "Shown" and "Decorator".

Shown are directly shown in the editor, together with their "name" attribute.

Decorator are not shown. They have a reference "using" to a Shown element, which must be decorated.

Doing that is really easy: I only have to implement method ToolBehaviorProvider.getDecorators, inspect the model, and verify if a given function has one or more D element referencing it.

However, the real problem is reacting when the model is changed. In this case, I was not able to use the notification service to update the function being referenced by the newly created Decorator. I think that the problem is in two places: (1) my model is silly (but I'm forced to use it) and (2) the notification service (class DomainModelChangeListener) triggers the updates starting from the notifier of the ResourceSetChangeEvent. This way, when a new Decorator is added, the updates comes from the Model, and I cannot figure out which Decorator is referenced.

How can I solve this? Are there guidelines on how to use Graphiti's service and deal with silly models?
Re: NotificationService & Updates [message #757133 is a reply to message #757131] Wed, 16 November 2011 11:56 Go to previous messageGo to next message
Tim Kaiser is currently offline Tim Kaiser
Messages: 118
Registered: July 2009
Senior Member
Hi,

you can overwrite the method
calculateRelatedPictogramElements(...)
in the DefaultNotificationService.

Does it work?

Best, Tim
Re: NotificationService & Updates [message #757136 is a reply to message #757133] Wed, 16 November 2011 12:05 Go to previous messageGo to next message
Matteo Miraz is currently offline Matteo Miraz
Messages: 38
Registered: March 2011
Member
Hi

no, because when a new Decorator is added, I got a reference to the whole model (and not to the new Decorator).
I could state that all elements are related, but I don't like forcing a global update to detect the changed element...

Any other idea?
Re: NotificationService & Updates [message #757145 is a reply to message #757136] Wed, 16 November 2011 12:58 Go to previous messageGo to next message
Tim Kaiser is currently offline Tim Kaiser
Messages: 118
Registered: July 2009
Senior Member
Hi,

i expected that the newly created model object would be
reported (and not only the whole model). Did you debug DomainModelChangeListener?

If nothing helps, you could implement your own ResourceSetListener and add it to
the resource set. Then, you have the chance to inspect the ResourceSetChangeEvent/Notifications yourself and you can react accordingly and trigger updates/refreshes.

Best, Tim
Re: NotificationService & Updates [message #757147 is a reply to message #757145] Wed, 16 November 2011 13:45 Go to previous messageGo to next message
Matteo Miraz is currently offline Matteo Miraz
Messages: 38
Registered: March 2011
Member
Hi,

I've debugged the DomainModelChangeListener, and let me show the problem:

public void resourceSetChanged(ResourceSetChangeEvent event) {

	[...]

	// Compute changed BOs.
	final Set<EObject> changedBOs = new HashSet<EObject>();
	List<Notification> notifications = event.getNotifications();
	for (Notification notification : notifications) {
		Object notifier = notification.getNotifier();
		if (!(notifier instanceof EObject)) continue;
		changedBOs.add((EObject) notifier);
	}


As you can see, the changedBOs is calculated by considering notification.getNotifier(), that in my case is the model. I think that normally this is not an issue because elements are added by using an Add/CreateFeature.

In the meanwhile, I implemented my own ResourceSetListener, using DomainModelChangeListener as inspiration. I computed the set of changed elements and the dirty pictogramElements (using notificationService.calculateRelatedPictogramElements). However, if I invoke
notificationService.updatePictogramElements(dirtyPes);

the diagram is not updated correctly. Only a
diagramEditor.refresh();

shows the decorators.

What is the difference between the two methods? (I feel I made other errors, and I'd like to understand what's wrong)

Thanks again,
Matteo

[Updated on: Wed, 16 November 2011 14:43]

Report message to a moderator

Re: NotificationService & Updates [message #757234 is a reply to message #757147] Thu, 17 November 2011 04:37 Go to previous message
Matteo Miraz is currently offline Matteo Miraz
Messages: 38
Registered: March 2011
Member
Hi,

I (think) I found and solved my errors. Let me know if I'm wrong Smile

The elements I show in the diagram are only composed of a rectangle and a text. For this reason, my update feature only checks if the name is changed, in order to update the text of the rectangle.

Decorators are shown by using graphiti's decorators. These are not recalculated when I issue an update (maybe because my update feature says that everything is up to date). Accordingly, my diagram does not change when I invoke notificationService.updatePictogramElements(dirtyPes).

Conversely, refresh method performs a refresh of the element shown, including their decorators. Since I do have calculated the dirty pictogramElements, I should use the refresh method with a pictogram element as parameter (I did not noticed it), so I can force the refresh only on the dirty elements.

Thank you all for the support! I hope I have nailed it, and that this post might be useful for somebody else!

--
Matteo
Previous Topic:Setting of Diagram in the Diagram editor
Next Topic:Images in the diagram
Goto Forum:
  


Current Time: Wed Aug 20 08:54:53 EDT 2014

Powered by FUDForum. Page generated in 0.01890 seconds