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. :-|
<SNIP/>
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 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.
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.
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