Hi Wim, thanks. That feature would be a great and a big saver for boilerplate code. Maybe worth a bug report. Also you may want to consider suggesting a GSoC project for this feature.
Best regards, Lars 2013/3/7 Wim Jongman <[email protected]> > Brian, > > I have found some documentation about the adapter mechanism [1]. It would > be nice if the injection framework could automatically adapt (if requested). > > A frequent pattern obviously is adapting an object received from the > active selection. Currently you can ask the specific object you are > interested in like so: > > @Inject > public void someMethod(@Optional > @Named(IServiceConstants.Active_Selection) Person person) > > This has the convenience of only receiving Person objects. If the adapter > framework is active in this scenario then it would save even more > boilerplate code. > > @Inject > public void someMethod(@Optional > *@Adapt*@Named(IServiceConstants.Active_Selection) > *Person person*) > > <do something> > > instead of: > > @Inject > public void someMethod( > @Optional @Named(IServiceConstants.ACTIVE_SELECTION) *Object someObject*, > *Adapter adapter*) { > > Person person = adapter.adapt(someObject, Person.class); > if(person != null) > > <do someting> > > I think it is save to say that adaption is ALWAYS required because why > would there be an adapter otherwise? > > [1] http://wiki.eclipse.org/E4/EAS/Adapting_Objects > > Regards, > > Wim Jongman > > > On Wed, Mar 6, 2013 at 3:52 PM, Brian de Alwis <[email protected]>wrote: > >> I'm using the Adapter/EclipseAdapter — no need to implement. The default >> implementation (EclipseAdapter) saves a lot of boilerplate since the >> IAdapterManager doesn't do an IAdaptable check. I personally can't think >> of anything else to add to its interface. >> >> Re: Logger: agreed. The world doesn't need yet another logger interface. >> >> I wouldn't say IContributionFactory is ready as it doesn't have a story >> for extension points. >> >> Brian. >> >> On 5-Mar-2013, at 4:50 PM, John Arthorne wrote: >> >> Eric Moffatt wrote on 03/05/2013 04:13:56 PM: >> > Tomorrow I expect to have something on the Services; this is an area >> > that I'll likely need input on since I only use the EModelService >> > and EPartService. Tom, we're not going to declare the various >> > presentation / rendering API now correct ? >> >> FWIW, I scanned through the "core" services in >> org.eclipse.e4.core.services today. From what I can see, only IEventBroker >> is truly fleshed out and ready to be treated as API. Logger is probably >> used enough at this point that we'll need to keep it, although if I could >> do things over I'd pick the heavily used SLF4J Logger API for better >> interop with existing code. Many of the other services are used internally >> but I'm not sure we have proved they are valuable abstractions or just >> incomplete replacements for existing 3.x API. If any consumers are >> implementing their own IContributionFactory, Adapter, StatusReporter, or >> TranslationService I would be curious to know about them. If there are no >> strong use cases for making them API I suggest just leaving them as >> internal/provisional for this release. >> >> John_______________________________________________ >> e4-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/e4-dev >> >> >> >> _______________________________________________ >> e4-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/e4-dev >> >> > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > >
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
