I will wait for an answer of Brian and then file the report. Do you want me to create a topic in the course about the adapter framework? Everything okay in Italy? Vincenzo picking it up?
Regards, Wim On Thu, Mar 7, 2013 at 8:22 PM, Lars Vogel <[email protected]> wrote: > 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 > >
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
