no, we were trying to make it easier for multiple plugins to extend the request processing pipeline. there is nothing wrong with subclassing.
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. the simplest solution is, imho, the best. subclass requestcycle and override ondetach() -igor On Tue, Jun 21, 2011 at 8:08 AM, James Carman <[email protected]> wrote: > Subclassing sucks! I thought we were trying to go away from that. > > On Tue, Jun 21, 2011 at 11:05 AM, Igor Vaynberg <[email protected]> > wrote: >> it seems the only usecase where this is needed is for code that >> validates that everything has been properly detached. but, for that to >> work you will still need to ensure that your validating listener's >> onendrequest() is the absolute last thing that is called. with >> multiple listeners and with us not guaranteeing their invocation order >> you still have a problem of ensuring your validating listener is >> invoked last. >> >> the easy way to do this is not to use a listener and subclass >> requestcycle#onDetach(), call super.onDetach() first, and then do your >> validations. >> >> -igor >> >> On Mon, Jun 20, 2011 at 5:53 AM, Martijn Dashorst >> <[email protected]> wrote: >>> On Mon, Jun 20, 2011 at 1:39 PM, Martin Grigorov <[email protected]> >>> wrote: >>>> I think the change in the ordering is (Igor's reply earlier in this thread) >>>> "a) it is dangerous to provide a method that is called after detach() >>>> because it can potentially reattach state." >>> >>> It is dangerous to step into a car since you can potentially drive >>> into a tree... >>> >>> The functionality was there to begin with (prior to 1.5), I haven't >>> heard of anyone doing bad stuff which wasn't easily fixable, yet >>> removing this makes life harder for folks that depend on the original >>> behavior. The whole idea of request cycle listeners is to replace the >>> need for the One and True RequestCyle. >>> >>> And I like the symmetry: onBeginRequest() happens right at the >>> beginning of the request—nothing happening before, onEndRequest() >>> happens right at the end of the request— nothing happening after. >>> >>> Martijn >>> >>>> >>>> On Mon, Jun 20, 2011 at 12:09 PM, Martijn Dashorst >>>> <[email protected]> wrote: >>>>> All wicket versions prior to 1.5 had onEndRequest after onDetach. I >>>>> don't see a big problem with changing the order to how it used to be. >>>>> I'd like the change go into 1.5RC6 (or 1.5RC5.1) >>>>> >>>>> Martijn >>>>> >>>>> On Tue, Jun 14, 2011 at 8:51 AM, Emond Papegaaij >>>>> <[email protected]> wrote: >>>>>> The Wicket 1.4 RequestCycle also provided 3 'onFinish' methods: detach, >>>>>> onAfterTargetsDetached and onEndRequest, which were invoked in that >>>>>> order. >>>>>> Perhaps, the solution is to move onEndRequest back to its old position, >>>>>> after >>>>>> onDetach? It used to be a method that was called at the very end of the >>>>>> request, even after the pagemap lock was released. >>>>>> >>>>>> On Monday 13 June 2011 21:19:31 Martin Grigorov wrote: >>>>>>> -0 >>>>>>> >>>>>>> I also don't like having so much "onFinish" methods (currently there >>>>>>> are onEndRequest() and onDetach()). >>>>>>> I also suggested to Emond in IRC to extend RequestCycle class (option >>>>>>> b) below) but now I think he will need to tweak BaseWicketTester >>>>>>> because it has its own RequestCycle and this may be tricky. >>>>>>> But even with this reason I still don't like to have three step >>>>>>> on-finish. >>>>>>> >>>>>>> On Mon, Jun 13, 2011 at 10:04 PM, Igor Vaynberg >>>>>>> <[email protected]> >>>>>> wrote: >>>>>>> > -0 >>>>>>> > >>>>>>> > like i said in jira, >>>>>>> > a) it is dangerous to provide a method that is called after detach() >>>>>>> > because it can potentially reattach state. a lot more people are >>>>>>> > familiar with "destroy" rather then "detach" so without reading >>>>>>> > javadoc that seems like a better method to override - which is >>>>>>> > incorrect. >>>>>>> > b) this can still be accomplished by subclassing requestcycle's >>>>>>> > detach() and calling super first in the override. >>>>>>> > >>>>>>> > -igor >>>>>>> > >>>>>>> > >>>>>>> > On Mon, Jun 13, 2011 at 11:54 AM, Martijn Dashorst >>>>>>> > >>>>>>> > <[email protected]> wrote: >>>>>>> >> +1 >>>>>>> >> >>>>>>> >> On Fri, Jun 10, 2011 at 10:52 AM, Emond Papegaaij >>>>>>> >> >>>>>>> >> <[email protected]> wrote: >>>>>>> >>> Hi all, >>>>>>> >>> >>>>>>> >>> With the migration from Wicket 1.4 to 1.5, we tried to rewrite our >>>>>>> >>> custom request cycle code into IRequestCycleListeners. This worked >>>>>>> >>> for >>>>>>> >>> most of our code, except for one use-case: running code after >>>>>>> >>> everything is detached. In Wicket 1.4, it was possible to use the >>>>>>> >>> onAfterTargetsDetached for this, but a similar method is not >>>>>>> >>> available >>>>>>> >>> in IRequestCycleListener. >>>>>>> >>> >>>>>>> >>> I opened a ticket for this (WICKET-3695), but it was closed by Igor. >>>>>>> >>> After a bit of discussion (see the issue), he suggested to start a >>>>>>> >>> vote here; so here it is. We would like the addition of onDestroy to >>>>>>> >>> IRequestCycleListener, which is called after everything is detached. >>>>>>> >>> This would serve to tear down request state that is still needed >>>>>>> >>> during detaching. >>>>>>> >>> >>>>>>> >>> Best regards, >>>>>>> >>> Emond Papegaaij >>>>>>> >> >>>>>>> >> -- >>>>>>> >> Become a Wicket expert, learn from the best: >>>>>>> >> http://wicketinaction.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Martin Grigorov >>>> jWeekend >>>> Training, Consulting, Development >>>> http://jWeekend.com >>>> >>> >>> >>> >>> -- >>> Become a Wicket expert, learn from the best: http://wicketinaction.com >>> >> >
