Our most important usecase is destroying request context that is still needed during detach. We simply require this action to be performed after detach.
Emond On Tuesday 21 June 2011 17:05:47 Igor Vaynberg 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
