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
