Community
Participate
Working Groups
There might be cases, when generated editor is not satisfied with a class available from runtime and needs it slightly tuned, though the change is not that general to get propagated to runtime (or it's general enough but is not yet part of runtime). Often, such classes are used in few places throughout generated code, and present approach, with new anonymous inner class being injected each time it's needed is superfluous and troublesome. Examples include identical NonResizableEditPolicy subclass for each node label, or ListCompartmentEditPolicy from bug #147855. Hence, there's need to get such classes generated only once (and only if needed) and reused throughout generated editor.
BTW, subclasses of NotResizableEditPolicy (added with bug #149041), may be replaced with: installEditPolicy(EditPolicy.PRIMARY_DRAG_ROLE, new SelectionHandlesEditPolicy() { protected List createSelectionHandles() { return Collections.singletonList(NonResizableHandleKit.moveHandle((GraphicalEditPart) getHost())); } }); Besides, if no policy is installed at all, label seems to be unmovable, hence it's not clear what was the original reason for the bug #149041. Perhaps, there's some other change meanwhile that resulted in label not being movable? It might turn out we don't need any editpolicy at all (if we are fine with default selection)
Note: bug #245158 adds more code into the editpolicies subclasses of NodeLabelEditPart.xpt, and might need to be concidered when performing the change.
Both NodeLabelEditPart and LinkLabelEditPart has been refactored to generate respective EditPolicy class only once (as nested class in diagram's EditPart). Although this is a huge leap forward, it is still not the best solution, imo (I'm looking for a generic/consistent way to solve such issues)
[GMF Restructure] Bug 319140 : product GMF and component Models - Generation was the original product and component for this bug
