Community
Participate
Working Groups
For refactoring-operations, the serializer might not be invoked on the original model, but on a smaller *copied* version of a subtree of the model. This is reasonable to have a fast an robust mechanism to calculate the text-changes that will eventually be applied by the refactoring. serializer 1.0 (ParseTreeConstructor) has no API to support this. in serializer 2.0, the SemanticNodeProvider could need a mechanism to supply a copiedEObject-to-originalEObject mapping. workaround: subclass the SemanticNodeProvider. Furthermore it needs to be ensured that all other components of the serializer only traverse the node model but don't access the node adapters or node.getSemanticObject().
Since EObject's equality is based on identity, this sounds like a very errorprone approach to me. Utilities such as NodeModelUtils make assumptions on the invariants of the node model such as the node is an adapter for the EObject that's returned by #getSemanticEObject if #hasDirectSemanticElement is true etc. I think the approach that is followed by the refactoring framework is more promising. That is, perform the modification on an own resource set.
See comment 1 also IMHO this kind of problem should be handled specifically.
