Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] E4 Formal API Part 2: UI Model

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 <briandealwis@xxxxxxxxx> 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
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev


_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev



Back to the top