Ralph Goers wrote: > > Do you have any details of where you want to go with this? Is it safe > to assume you want to deprecate Subscriber? Yepp - the whole event manager/subscriber/publisher/register thing is imho way too complex. So I merged publisher and register into the event manager and simplified the subscriber (which is now called receiver). During the various projects we've done with the portal, it turned out that most of the work is adding your own events and create some subscribers for the events. And I think the current solution requires too much coding. For example the new Receiver interface passes not only the event but also the PortalService to the receiver, so the receiver has access to the whole portal without requiring to implement any lifecycle methods. I have no concrete ideas yet, but I want to simplify the receiver in a way that you don't have to implement the interface anymore (Don't know how yet :) ). And I'm interested in enabling scriptable event receivers - for example write your receiver in flow script. But these are just some rough ideas.
> > While sort of on the same topic, I would like to move in the direction > of not exposing event ids in URLs, at least as far as possible. I > started this with a couple of events but I haven't done all the ones > that could be. > Yeah, this is a very annoying topic. If you have any suggestions we should talk about them. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
