Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 346739

Summary:	[Palette] New framework breaks inherited diagrams
Product:	[Modeling] Papyrus	Reporter:	Yann Tanguy <yann.tanguy>
Component:	Core	Assignee:	Yann Tanguy <yann.tanguy>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	eclipse-bugzilla, sebastien.gerard
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:
Bug Depends on:
Bug Blocks:	348866

Description Yann Tanguy

2011-05-20 12:58:47 EDT

The new framework relies on modified generated ViewProvider (for GMF diagrams) which prevents ViewProvider to be always activated in ViewForKind (current diagram type is now checked).
This is probably an improvement but lets keep in mind that Eclipse may register other GMF generated diagram without this modification, so dont be too confident in this.
The problem with the inherited diagram was that they assumed (except BDD) the provides (for Kind) to always return true in the super class, this is not the case anymore.

Comment 1 Yann Tanguy

2011-05-20 13:03:36 EDT

In r4751:
- Fix for Package, Requirement and Internal Block Diagrams.

Comment 2 Yann Tanguy

2011-06-09 07:02:45 EDT

Some issues remains in 0.8.0 RC3 (BDD Especially)
- The provides (ViewForKind version) of the ViewProvider for inherited element is not restrictive enough, once activated, it always return true whatever the IElementType.

1. We should investigate in Papyrus a way to avoid relying on this method which default implementation is incorrect (other diagram may corrupt ours).
2. When implemented in Papyrus, the implementation should take the diagram type / container type / sem. hint into account in the provides method.
3. The CreationEditPolicy should maybe ensure a view can be created before returning a command for view creation.

Comment 3 Yann Tanguy

2011-07-07 16:48:00 EDT

In r5003 : Fix in oep.sysml.diagram.common

- "provides(CreateViewForKindOperation op)" from ViewProviders is not reliable and should not be used in BDD
	- Throw an exception in this method to avoid it to be used
	- Make sure the exception is only thrown when an unexpected diagram ask for provides (return false in such a case)

- Modify the following EditPolicies (responsible for view creation) so that they return a view creation command with a different canExecute() implementation:
	- ContainerNodeEditPolicy
	- CreationEditPolicy
	- GraphicalNodeEditPolicy
	
- CreateViewCommand replace CreateCommand with a new canExecute() method that never rely on provides(CreateViewForKindOperation op) to know if a ViewProvider can provide a View.

Comment 4 Yann Tanguy

2011-07-27 04:23:36 EDT

(In reply to comment #3)
> In r5003 : Fix in oep.sysml.diagram.common
> 

Merge in trunk : r5129.

Comment 5 Yann Tanguy

2012-10-05 11:16:31 EDT

Not relevant anymore, IBD and BDD now avoid the use of "provides(CreateViewForKindOperation op)".