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).
Still, DefaultChangeAspectDataEventSubscriber is a hack since components should subscribe themselves instead of this proxy.
<SNIP/>
So you agree with the assessment on pulling in layouts and event targets?
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 "persistent" one) for the EventManager without changing the current portal behaviour. It's an add-on then.
Well, yes. But since it removes the need for the DefaultChangeAspectDataEventSubscriber band-aid, I would want to change the behaviour of eg layouts to subscribe themselves. And the bahaviour of renderers to emit events that don't carry object references. This
would lead to duplication of large sections of the current portal
engine if done as add-on.
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
I believe you are talking about EventConverter-s. These are a bit difficult to do since they would need knowledge of event internals in order to convert them to / from strings for example. It really should be the task of an event to convert itself.
it for every event. Think of inter-coplet communication where one coplet sends an event to other coplets with a whole bunch of information.
Ah, I see. There might be events that are never send to the client but stay on server-side. They are created and consumed during the portal setup phase. IMO it would be sensible to introduce two classes of events, then. "event-is-attachable-to-link" and "server-side-event". The former must be able to convert to/from string and the latter need not. However, I don't think any event should be "targeted" at a specific subscriber instance. This is not the business of an event publisher (see ChangeAspectDataEvent, IMHO this is bad).
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08