cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: portal engine / design
Date Sun, 09 Nov 2003 15:04:03 GMT
Christian Haul wrote:
> 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.
>
Yes, it's a hack and yes components should subscribe themselves, but data
objects are not components and therefore shouldn't subscribe! E.g.,
layouts, coplet data etc. are "only" data objects and not components and
therefore imho they shouldn't subscribe. You can send an event to
a managing component but not to the data itself.

> >><SNIP/>
>
> So you agree with the assessment on pulling in layouts and event targets?
No :)

>
> >>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.
>
As I said above, I'm absolutely against adding logic to the data
objects, like the layout.

> >>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.
>
An event is only data (= message). We discussed this topic in length
during the design phase and honestly I can'T remember why we choose
this way :) Have to think about it...

> > 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.
Personally, I don't like all this conversions. The current approach
avoids costly serialization and is independent from the events.

> 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).
The event is not targetted at the aspect data, but at a component that
is able to do something meaningful with this event which is in this
case change some data.

Carsten


Mime
View raw message