> 3. @peter [2]_ if `old_values` is considered to be yet another > instance of event arguments then all methods will have > the same interface > * which makes me wander whether they should be > merged into a single method plus event name > included as argument or another field in event args > object (i.e. `context` in signatures above) In this case, we are moving dispatching logic from the Trac core to event consumers. Current proposal already brings some dispatching logic on the event consumer side - when a consumer subscribes for events from multiple types (e.g. ticket and milestone). Adding event name as a parameter will complicate the event consumer dispatching even more.
Stepping back, I'll try to summarize which problems the proposal should to solve: - Introduce common denominator for a entity changed events (in future, new events can be added such as manipulator/before-change and during-changing events). - Avoid manual maintenance and documentation of I*ChangeListener interface per entity (currently, there is 11 such entities in Trac). - Extendibility for plugin entities - Provide simple subscription for events of specific entity (e.g. only ticket changed events) with possibility to listent to multiple types events. - Do not re-lay dispatching logic on event listeners Is the summary more or less correct? Based on the received feedback, I'll try prepare alternative to IResourceChangeListener implementation that we can compare pros and cons of different approach. Cheers, Andrej -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/trac-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
