> -----Original Message----- > From: Olemis Lang [mailto:[email protected]] > Sent: Wednesday, 10 April 2013 1:47 PM > To: [email protected] > Subject: Re: Transaction resource changing events > > On 4/9/13, Andrej Golcov <[email protected]> wrote: > >> Would it not make more sense if this code were simply committed into > >> an appropriate place in trunk? Or even better, quoted inline in this > >> message, so that it gets archived along with the rest of the mailing > >> list? AFAIU pastbin links are not eternal, which could make > >> reconstructing this discussion from archives a bit of a chore. > > Pastebin.com links may be eternal , that depends on how they are created . > For instance , all those I've created in the past for test reports are public and > <everlasting> . The ideal solution would be to have a pastebin installed in > apache.org domain . Ryan and me have been tweaking > trachacks:PastebinPlugin user interface for that very same purpose in the > past . I'm hoping this will be available for us ... > eventually . >
paste.apache.org Gav... > > I haven't sent the code in mail since python markup can be messed by > > email > > + > besides , at least outside the ASF , it's not a good practice to submit such > texts to public MLs > > ... to the point ... > > [...] > > 'context' is an action context, may contain author, comment etc. > > Context > > content depends on a resource type. > > ... 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) . > > > > > def get_subscribed_resources(): > > """ > > Implementation should return iterator of resource types for which > > a listener has to be notified. > > > > None or empty list means all types of resources. > > """ > > > > def match_resource(resource): > > """Return whether the listener wants to process the given > > resource.""" > > > > + , these should work exactly the same as listeners will do , though > we still have to find the BH-spot of this subject (see #485) > > > def resource_creating(db, resource, context): > [...] > > > > def resource_changing(db, resource, old_values, context): > [...] > > > > def resource_deleting(db, resource, context): > [...] > > > > Just a question . Are these methods supposed to replace manipulators ? > > - If so , how will they veto subsequent processing ? > - Else , isn't it a fact that methods listed above and > manipulators have a lot of overlapping (duplicated > functionality) ? > * Or maybe the idea is to replace manipulators with > this interface and provide backwards compatibility , just > like has already been done with IResourceChangeListener ? > > 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 . > > -- > Regards, > > Olemis.
