On 4/18/13, osimons <[email protected]> wrote: > On 18 apr, 15:18, Andrej Golcov <[email protected]> wrote: >> I've just added an alternative proposal as comment on the >> ticket:http://trac.edgewall.org/ticket/11148#comment:5 >> >> Please share what do you think on this. >> >> Cheers, Andrej > > I've added a brief comment, and as far as I can see this works exactly > like Listeners do today? > > Anyway, let's take a step back first: > > I'm not saying the current *Listener interfaces are perfect. Far from > it. The main problem in my mind is that they are already way to > limited due to the limited data they get passed. Like no request > context,
what if there's no such context e.g. trac admin command ? > no user, maybe usefull yes . > no permissions. what would these be for ? > The things you can do in and around > Trac without user and permission information is very, very limited. > Really restricted to just doing 'bookkeeping' in plugins that create > related data structures behind the scenes - like how deleting a ticket > could also delete tags pointing to it, for instance. > > The need for 'generic' notification and similar user-facing needs has > been mentioned many times in this thread, but that seems to not quite > see the whole picture as without user and permission you cannot > notify. > If you change a ticket that is marked as 'private' through > some security policy, no listener (generic or otherwise) have the > required information to enforce security before passing the > information along to users. What you can safely do with generic > notifications is very limited. > I disagree especially considering your example. On ticket change you'll only be able to figure out the permissions context of the actor performing such action , which is guaranteed to be allowed before actually changing the entity . Now that it was successfully changed , as it's private what needs to be considered is the permissions of *other* interested (subscribed) parties . The way I see it now (but I might be missing something) it's impossible to design the listeners API based by cluttering it with data reflecting external influences . In your example ticket ID is well known by listener (be it in model , resource, ...), access rules may be retrieved somehow . So just let the listener put all the pieces together to get thins done . > This is main reason why our notification system (trac.notification) > for the large part have retained its pre-0.9 implementation. Not much > in the way of API-based thinking in the deep corners of that sub- > system... The lack of better internal notification/listener interfaces > is the number one reason why. It really should have been completely > redone to only use *Listener interfaces instead of the direct call > architecture we still use. > +1 ... somehow we've been decoupling handling of certain things in Bloodhound multi-product plugin by implementing product listeners . What you mention is much more complex though as concerns involved impact across multiple realms > To further add to the perspective I'd also like to mention our > *Manipulators as their issues are somewhat related - and yet > completely different. +1 > These are usually much more 'powerful' > interfaces that allows us to do much more - we usually have a request > with perm, user and all we need. The problem then is that it actually > becomes hard to use when not accessed through the web interface. Yes , such a headache . > Which > is why for instance the ticket-commit-updater component that gets > called from repository hooks (via 'trac-admin changeset added') can't > call manipulators, and only calls out to listeners inside ticket > save_changes() as that don't depend on a 'req'. > This can all be found > in http://trac.edgewall.org/ticket/10125 for those interested. > > Complex non-obvious objects with unbounded storage options should not > be passed as part of APIs. Even 'req' fails this test because we > cannot faithfully recreate all parts and variations outside a request > context. So let's instead gather the bits we all should depend on and > that would be the minimum set needed to do useful work in all > contexts. perm, user, resource and href is a good start, and pass each > as named arguments and set to None if unavailable. I do not agree . This is similar to rendering context . It's a single object , so related changes are encapsulated in that single class (as much as possible ;) . Even different contexts may be represented by different classes satisfying the same contract under different constraints . However changing method signatures is much more complex > In a pinch I would > settle for using a well-defined OfflineRequest with essential data and > passed as 'req'. > We do that in Bloodhound (i.e. `bhdashboard.util.dummy_request` ) to reuse Trac code in Bloodhound widgets . -- Regards, Olemis. Apache™ Bloodhound contributor http://issues.apache.org/bloodhound Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: -- 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.
