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 <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
