> ... a comment that's also valid for IResourceChangeListener . In Trac > , `context` is a variable name associated to instances of > `trac.mimeview.api.RenderingContext` (similar to `env` for > `trac.env.Environment`) . Therefore it's a bit confusing in this > context (at least for me that I'm familiar with that term and how it's > used in Trac code base ;) since it clashes with that inherited > *convention*. Is there a chance to name these objects somehow > different ? > > 1. evt (dojo) > 2. eventObject (jquery) > 3. EventArgs (C#) > 4. ... > > If you ask me I prefer (3) or (2) . AFIK, "context" parameter is used in multiple places in Trac with meaning of context e.g. in resource ResourceContext, in versioncontrol in wiki formatters. IMHO, by renaming the context parameter to event(Args|Object) we are losing meaning of this parameter - context in wich event is triggered. I will start discussion on Trac dev group on previously introduced IResourceChangeListener interface in order to get more feedback and see if it can accepted by Trac community.
> Just a question . Are these methods supposed to replace manipulators ? No. Manipulators events are called before the modification transaction is created and can be used for the resource manipulation and validation. While IResourceChangingListener events are to be called after DB modification is done but before DB transaction is committed. These events can be used for additional DB actions that should be atomic with the resource DB modification. In our case, it is modification of the ticket-relation table atomically with the ticket CRUD operation. I agree with Peter, that the usage of the interface should be very clearly documented in order to avoid possible abuse because long running transaction can influence the overall system performance. > Beyond that > > - add reparent events > - 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) > * and , by doing so , subsystems would even be > able to define their own event types without > requiring major architectural refactoring . IMO, using granular interfaces provides documentation by code. While more generic events make developer to rely on documentation (that is not the strongest part of the open-source) and debugging. Cheers, Andrej
