Hi team!
In my new day job I've been spending a lot time with Cocoon's portal
engine. Since we would like to have bookmarks and (for simple portals) be able to offload serving to a httpd, I spend some time looking deeper
at the internal mechanics and the event system.
It appears, that the publish / subscibe paradigm doesn't match the problem at hand good enough. At least a number of things looked like they were band-aids to make it fit.
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.
Another issue with pub/sub is, that layout elements need to be informed. Unfortunately, for this they would need to be instantiated before the event is published. Which cannot be guaranteed. The band-aid here is to load layout elements when generating links (which means pulling in a whole bunch of perhaps never needed layouts when displaying a page), have an additional indirection, the above DefaultChangeAspectDataEventSubscriber, and putting a hardcoded target ie an object reference into the event.
This works, because currently the events themselves are stored inside the session -- otherwise object serialization would be needed. In addition, the interface does not require serializable event content.
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.
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.
I would like to have, but don't have a brilliant idea, yet, is to be able to ask layout elements (or any other event subscriber) to define their state relative to their default in terms of events.
Fire at will ;-)
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