>What would this look like in multi-selection cases ? I'm not sure that "List<Person>" is DI-able but I could be wrong...
Works fine, e.g. with the ESelectionService. 2013/3/7 Eric Moffatt <[email protected]> > > Wim, to paraphrase a joke I know "I like the way you think" :-)...this is > the kind of simplification for the *user* that I like to see. > > What would this look like in multi-selection cases ? I'm not sure that > "List<Person>" is DI-able but I could be wrong... > Would the adapted method only be called when there's a valid Person ? > Likely yes is my guess. > > The biggie is who's going to take over the DI code ? The person who wrote > the current implementation has moved on so there's nobody here that is > familiar with the code. Since DI really is turning into the most 'active' > area (new annotations..) it would be great if someone were to take > ownership of it. > > Onwards, > Eric > > > From: Wim Jongman <[email protected]> To: > E4 Project developer mailing list <[email protected]> > Date: 03/07/2013 01:55 PM Subject: > Re: [e4-dev] E4 Formal API Part 2: UI Model > Sent by: [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*<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]*<[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]* <[email protected]>* > **https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev> > > > _______________________________________________ > e4-dev mailing list* > **[email protected]* <[email protected]>* > **https://dev.eclipse.org/mailman/listinfo/e4-dev*<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
