cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: portal engine / design
Date Sun, 09 Nov 2003 09:55:43 GMT
Christian Haul wrote:
> Subscribers register themselves with the EventManager. However, in order
> to do this, they need to live in the same component manager space as the
> portal. This prevents e.g. startable + threadsafe components to
> subscribe. As a consequence, the DefaultChangeAspectDataEventSubscriber
> is hardcoded into the DefaultEventManager.
No, this is not true :) The DefaultChangeAspectDataEventSubscriber is
actually a hack as it was the fastest way of getting it done. A better
way would have been to make the EventManager configurable with default
subscribers or to place the DefaultChangeAspectDataEventSubscriber
"somewhere elsed and let it subscribe by itself".
Each component can subscribe, regardless in which CM it is defined (at
least in theory).

> <SNIP/>
> Now, I would like to do the following:
> Upgrade the pub/sub system with "persistent" delivery. IOW events
> from the current request will be delivered to every new subscriber.
> This way DefaultChangeAspectDataEventSubscriber can be discarded and
> e.g. Layouts can subscribe themselves. Obviously, "persistence" would
> end at the end of the request.
Hmm, not sure if this is a good idea - have to think about it. But anyway,
you can change this by choosing a different implementation (your
one) for the EventManager without changing the current portal
behaviour. It's an add-on then.

> Another effect would be, that change events would be able to target
> any layout that fills a specific role (the ID).
> Have EventManager use SoftReferences (-> JCC) to register subscribers.
> Add a name attribute to events and permit a subscriber to select
> only events of a particular class AND a matching prefix for the name.
> IMO the class resembles a JMS topic and the prefix would resemble the
> JMS select. Putting this into the EventManager allows for optimizations
> there and saves subscribers from implementing this logic.
> Require events to be able to convert themselves to / from String.
This is already implemented I think somehow, but you can't require
it for every event. Think of inter-coplet communication where one
coplet sends an event to other coplets with a whole bunch of


View raw message