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
I agree that IEventBroker is already really good and should be released. I only would like to add that platform should IMHO switch to use dependency injection for the event notification instead of manual event listener registration. I see the manual registration is still heavily used in the Addons, e.g. in the DnDAddon class and the renderer framework, e.g. in the StackRenderer class as examples.

I think platform should switch to use the following pattern:

@Inject @Optional
void closeHandler(@UIEventTopic(TOPIC_BLABLA) Event event) {
    // Do something
}

Best regards, Lars

2013/3/5 John Arthorne <John_Arthorne@xxxxxxxxxx>
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


Back to the top