On Tue, Jun 21, 2011 at 8:44 AM, James Carman <[email protected]> wrote: > On Tue, Jun 21, 2011 at 11:16 AM, Igor Vaynberg <[email protected]> > wrote: >> no, we were trying to make it easier for multiple plugins to extend >> the request processing pipeline. there is nothing wrong with >> subclassing. >> > > Except when you have multiple plugins trying to get their logic > plugged into the same place.
that is why we have listeners. >> really, what is the alternative? Martijn needs a guarantee his >> listener is executed last in order for his detach test to hold water. >> so, how do we do that? we can guarantee the invocation order, but how >> does Martijn guarantee someone else doesnt add a registerlistener(foo) >> after his? we can add irequestcyclelistener#getweight() and keep the >> listeners in a priority queue? how does Martijn then guarantee that >> only one listener has the priority zero? now we need a >> ireqestcyclelistenerlistener. >> > > I don't really know the complete context here. Are you just trying to > get a test case to pass or is it the case that you need some listener > to always be executed last, even at runtime? Martijn needs code to run *after* everything has been detached. >> the simplest solution is, imho, the best. subclass requestcycle and >> override ondetach() > > Yes, it's simple, I agree. I don't agree that it's the best solution > for folks who want to extend the framework, though. It's just not an > option for people who want to develop frameworks or plugins that can > just be "dropped in" and they work. when you need some sort of guarantee that you run "last" i dont see a "better" way -igor
