Am Dienstag, 3. Februar 2004 14:44 schrieb Oliver Zeigermann: > Daniel, > > could you please explain what are the main differences between your > Events and the existing Interceptors? Why wasn't it possible to just > augment the Interceptors? > > This might help people evaluating your patch :)
The main difference is that the events are fired in almost every module of slide. So it is possible to listen to webdav methods as well as for locking for example. The events that occur inside a transaction are vetoable, so you can reject a method by throwing a veto exception with a given reason. All events that are fired within a transaction can be collected by special event listeners (EventCollectors) so that you can listen on event bundles. These bundles are suited if you want to do something before transaction commit or after commit and want to take all events that occured inside the transaction into accout. If you want to update a search index for example you can simply add a collection listener and you'll get all events in the correct order after transaction commit. There is a helper class called EventCollectionFilter that you can ask for all changed contents (imagine if someone is creating and deleting the same resource in a single one transaction this will be filtered out by the collection filter). Events are very fine grained configurable and performance optimized so that no temporary objects are created when events are disabled. You can extend the events that are fired without changing any core classes. So the webdav events are totally independant from the /share classes. There is still some work and documentation to do, but I'd like to know if someone has any comments/suggestions on the event stuff. Daniel > > Oliver > > Daniel Florey wrote: > > Hi, > > I've attached an improved version of the event patch. Now the events can > > be configured in a sophisticated way to enable just the events you are > > interested in. > > You can enable groups of events (e.g. only content events or lock events) > > or event single methods (e.g. only store content). > > The event mechanism can be easily extended by adding custom events > > without changing any class in the share packages. > > I'll write a detailed documentation soon... > > > > Daniel > > > > I hope for some votes so that Oliver can check it in without fear ;-) > > > > Am Donnerstag, 29. Januar 2004 17:10 schrieb Daniel Florey: > >>Ok, > >>so this is the patch + the classes I've added. > >>If someone want's to give it a try, please add the following to your > >>Domain.xml to check if events are generated: > >><slide> > >>... > >> <!-- Event configuration --> > >> <events> > >> <listener classname="org.apache.slide.util.event.EventLogger" /> > >> <listener > >> classname="org.apache.slide.event.VetoableEventCollector" /> <listener > >> classname="org.apache.slide.event.TransientEventCollector" /> </events> > >></slide> > >> > >>The event logger will log all events using the domain logger. > >>The event collectors can be added to generate events called > >>EventCollection. The contain all events that are fired inside one single > >>transaction. So if you want for example update the search index for all > >>resources that changed in a transaction you can use the collections for > >>this. > >>You can add custom listeners that have to implement one of the listener > >>interfaces or have to extends the given adapters. > >>I'll document the package as soon as possible. > >> > >>Daniel > >> > >>Am Donnerstag, 29. Januar 2004 15:36 schrieb Oliver Zeigermann: > >>>I'd like to have the proposal on the list as soon as possible :) > >>> > >>>Oliver > >>> > >>>Daniel Florey wrote: > >>>>Hi, > >>>>In the last days I've been working on events for slide. It is really > >>>>not yet perfect, nor is it well documented - but they are working So > >>>>there is a lot of work for me to do. > >>>> > >>>>Nevertheless I'd like to send the patches and classes to the list as > >>>>soon as possible to let all of you participate in the earliest possible > >>>>stage as I don't want to go into the wrong direction. > >>>>What do you think? Send now or do some documentation/implementation > >>>>improvements first? > >>>> > >>>>Daniel > >>>> > >>>>--------------------------------------------------------------------- > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>>>. > >>> > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>>------------------------------------------------------------------------ > >>> > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
