Re: [e4-dev] IPartListener - really once more Listeners?

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

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


Paul Webster ---07/29/2013 01:13:39 PM---On Wed, Jul 24, 2013 at 5:18 AM, Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>wrote: > Hi,

From:	Paul Webster <pwebster@xxxxxxxxxxxxxxxxxxx>
To:	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
Date:	07/29/2013 01:13 PM
Subject:	Re: [e4-dev] IPartListener - really once more Listeners?
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

On Wed, Jul 24, 2013 at 5:18 AM, Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx> 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
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev