For me it seems like we'd be best off to add new life cycle events for these publish them. Then the logic for handling the 'registered' IPartListener's could hand off a listener on the event bus (i.e. the events *drive* the direct listener logic). The set of new events for this will match the existing 3.x part events unless someone comes up with use cases for others.
At the same time we should add at least a couple of rendering events
'PreRender' and 'PostRender' to manage some of the issues we have in the
IDE. For example we listen for 'widget' going non-null as an indication
that something has been rendered but this happens before the internal
structure has been rendered.
Are there others life cycle events that should be under discussion ?
Eric
From: Paul Webster <[email protected]>
To: E4 Project developer mailing list <[email protected]>,
Date: 07/29/2013 01:13 PM
Subject: Re: [e4-dev] IPartListener - really once more Listeners?
Sent by: [email protected]
On Wed, Jul 24, 2013 at 5:18 AM, Tom Schindl <[email protected]>
wrote:
Hi,
First of all I'm not sure why we are using Listeners here once more
instead of sending out the information through our EventBroker because
this once more traps our users into listener leaks.
We've been talking about this as well.
Our listener-for-information pattern has been replaced in Eclipse4 with
IEclipseContext.get(*) + the RATs (a unit of work that depends on that
information). But while this pattern is great for information (the active
part) and is scoped (the RAT is at a particular IEclipseContext instance)
it probably doesn't translated well for some of our larger listener
patterns, like partDeactivated/partHidden/partVisible etc.
So if firing events is a much better fit for events than the listeners, we
would need to look at 1) the pattern over a couple of listeners we want to
replace and 2) how can we scope it. ex: our IEventBroker.subscribe(*) can
take an LDAP filter as well as topic when registering a handler. Do we
need to add more information to our eventHandler properties that we use to
register as a service? Or is it properties in the event's that are posted
that need extra information.
PW
--
Paul Webster
Hi floor. Make me a sammich! - GIR
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
