Bug 495465 - Consider dropping the V-parameter of IVisualPart (and all related classes).
Summary: Consider dropping the V-parameter of IVisualPart (and all related classes).
Status: NEW
Alias: None
Product: GEF
Classification: Tools
Component: GEF MVC (show other bugs)
Version: 0.2.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: gef-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-04 08:40 EDT by Alexander Nyßen CLA
Modified: 2016-10-19 03:40 EDT (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Nyßen CLA 2016-06-04 08:40:09 EDT 
In addition to the VR-parameter that refers the the visual root (Node in case of JavaFX), IVisualPart also defines a V-parameter that refers to the concrete visual. This is problematic in two situations:

- When a Group is wrapped around the 'actual' visual, to include effect, etc. in the layout bounds, the 'actual' visual is not accessible without casting, so no benefit is brought by the V-parameter
- As the V-parameter fixes the return type of the createVisual() and getVisual() methods, and further is used within doRefreshVisual(V), subclasses cannot exchange the visualization of their superclasses.

We should thus consider dropping the V parameter and using VR in all places where V is currently used. We should also consider to remove the input parameter from doRefreshVisual(V) completely (the visual can be easily accessed from the respective getter, so there is no need to pass it in).