Yeah, let's make everything final! P.S. Ignore that.
On Tue, Jun 21, 2011 at 6:08 PM, 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 >>> >> > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
