I think the case that Mickael brings up here (which originated from here <https://github.com/eclipse/wildwebdeveloper/issues/294>) is a case where the extra context is already being passed in. The adaptableType already has the context that is needed to properly resolve - however unlike the column index, depending on the context a different adapter factory can do that resolution.
> Does anyone have some more knowledge about this area to share whether it seems like a good idea or not? I have been tripped up by this in the past, indeed CDT-DSF requires extenders to arbitrarily extend and reference a subclass so that a unique adaptable type object can be referenced by the adapter manager/extension point. It would be nice if any factory could provide such adaptions based on more than just the type of the adaptable object. Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Fri, 29 Nov 2019 at 06:57, Alexander Fedorov < alexander.fedo...@arsysop.ru> wrote: > 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 listplatform-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visithttps://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
_______________________________________________ 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
