Re: [platform-dev] Changing default IAdapterManager in Platform?

[Alexander Fedorov <alexander.fedorov@xxxxxxxxxx>]

Hi Mickael,

This is the common software evolution problem, now we want to consider multiple instances instead of the single one.
We have very similar problem for JFace label/content providers. Let me illustrate it with ITableLabelProvider that extends its "contextless" parent with methods like:

    public Image getColumnImage(Object element, int columnIndex);

So, here we have additional "columnIndex" argument to resolve the image, in our case the "context" is as trivial as one int. But we can consider passing some Function to generalize it.

I think the same idea may be applied for IAdapter framework : we can add a "context" Function to register/resolve  adapters according to the client needs.

Regards,
AF

29.11.2019 13:10, Mickael Istria пишет:

Hi all,

We've got an interesting case with LSP4E vs LinuxTools, both registering a factory with the same signature (adptableType -> adapterType). The dummy expectation was that it was legal to have multiple factories and that as long as the current factory returns null, another one would be tried and so on.

However, digging in the code of AdapterManager, it's actually keeping track of a single adapter factory, ignoring other ones. Which one is used is randomish and probably depends on bundle activation order or ordering in the extension registry. The AdapaterManager is documented to behave like this, we should probably not change it.

However, the IAdapterManager is more flexible and could allow implementations to keep and use multiple factories with same signatures. That would resolve our case and would more generally provide much more power and flexibility in usage and implementation of adapter factories.

So I'm considering writing and using in InternalPlatform a new implementation of the AdapterManager.

Does anyone have some more knowledge about this area to share whether it seems like a good idea or not?

Thanks in advance

--

Mickael Istria

Eclipse IDE developer, for Red Hat Developers

_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev