cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@informatik.tu-darmstadt.de>
Subject Re: portal engine / design
Date Sun, 09 Nov 2003 11:18:15 GMT
Carsten Ziegeler wrote:
> 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
haul@informatik.tu-darmstadt.de
     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08


Mime
View raw message