cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: portal engine / design
Date Sun, 09 Nov 2003 17:13:13 GMT
Carsten Ziegeler wrote:
> Christian Haul wrote:
>>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.

OK. What would be the managing component for a layout? The layout 
factory? Or the profile manager? But then the factory (at least the
default factory) would need to (a) keep a reference to all layouts
which it doesn't and (b) know how a layout behaves which it ....
doesn't. Actually, the renderers know that. So, renderers should
subscribe? They don't have a link to the layouts they render, the look
up works the other way around.

Mmmh, they could store the event until a layout comes by that matches
this event. :-|

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

Then I would really like some comments on this. You know, without docs
it's not really easy to understand the ideas behind it.

> As I said above, I'm absolutely against adding logic to the data
> objects, like the layout.

So it's the renderer, then?

>>>>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...

This works fine for intra-request messages. Inter-request is different.

>>>it for every event. Think of inter-coplet communication where one
>>>coplet sends an event to other coplets with a whole bunch of
>>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
> Personally, I don't like all this conversions. The current approach
> avoids costly serialization and is independent from the events.

It's the only way I see to have bookmarks or even think of going static.

>>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.

Granted. Still, I don't like the object references in a 
ChangeAspectDataEvent. This is hackish. Big time hackish.


C h r i s t i a n       H a u l
     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

View raw message