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 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
