In gmane.comp.version-control.subversion.trac.devel, you wrote: > Hey all, > >> It makes sense in theory, but not in practice. The way the system >> currently works is that plugins extend NotifyEmail. In their >> constructor the call NotifyEmail.notify, which calls there email >> constructing logic(get_recipients(), send()). Announcer seperates these >> steps into > > I've found extending NotifyEmail to be quite cumbersome. > >> Producer : produces and event >> Subscriber : figures out what users to notify of the event >> Formatter : creates the content for the event >> Distributer : actually create and distribute the email (including >> headers) > > I don't know if this will help, but I've been sitting on a patch that > attempts to refactor the notification system to utilize a listener > system (i.e. you pick the notification listeners you want to catch > events in trac.ini). I'll get it up on the trac site -- perhaps it > will be useful in this discussion. It is backwards compatible, but in > a fairly ugly way.
I'd love to see your work. >> Most plugins want to do the first three, but not that last one. > > I'd also add, with the last one, perhaps this isn't always an email -- > it really should be create and distribute the message... This is how announcer works, but it can be tricky at times. For instance, different types of events should get different email headers. It's hard to do this in a generic way. We create callbacks in announcer but now we have mixed concerns, the formatter knows about email. There isn't a super clean way to handle the problem. -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
