search

eclipsesource / papyrus-gefx

A new Editor kind for Papyrus, based on GEFx and GMF Runtime
0 stars 2 forks source link

[Dependency Injection] Support AdapterMaps overrides #31

Closed CamilleLetavernier closed 5 years ago

CamilleLetavernier commented 5 years ago

In #13, we added factory-based injection with priorities, to support injection of different types for different parts. This allows us to provide generic services for generic parts, and specific services for specific parts, when the generic behavior is not sufficient.

This approach works well for 1-1 injection, where the ContentPart knows exactly which service(s) it needs. However, interactions are based on adapters, and the Part doesn't need to know which adapters will be present at runtime; so we can't use the same approach (at least not directly).

We should find a solution similar to #13, but for interactions/adapters. For example, we want to provide a generic GMF implementation of the MoveNodeHandler, but still be able to override it for some specific content parts (e.g. for a PortContentPart with a custom Locator). However, AdapterMaps injection doesn't support conflicts/overrides; so we'll need a factory-based approach.

CamilleLetavernier commented 5 years ago

This task will be absolutely required before trying to support any model/diagram-specific customization, especially for behaviors or layouts (Styling is already OK)

CamilleLetavernier commented 5 years ago

A new AdapterHelper has been added, so we can now register multiple adapters with the same type

Priority is resolved from the Adapter's role if it's a number, or from the optional interface PrioritizedAdapter, which provides an explicit #getPriority() method. The priority resolution is executed only once per Adaptable (i.e. Part), and then the results are cached, so it shouldn't be more expensive than the standard GEF Adapter mechanism

This mechanism might ultimately replace the one from https://github.com/eclipsesource/papyrus-gefx/issues/13, which was a little bit too verbose and maybe not so useful after all. I'll implement a few more adapters/services with priorities, and if both mechanisms turn out to be redundant or conflicting, I'll remove the one from Issue #13 (But I'll open a follow-up ticket for that when/if it's required)