I sympathize with your situation, but IMHO it's reasonable to require AbstractAjaxBehavior#getCallbackUrl to happen during rendering. I'm actually confused about how the behavior can get its URL during construction, before it's associated with a page. I tried in quickstart and it blew up with "No Page found for component".
Maybe getCallbackUrl should issue a warning if called outside render phase. It's not obvious to me how it can determine this, though. On Thu, Mar 22, 2012 at 3:55 AM, Pointbreak <[email protected]>wrote: > We have recently upgraded our application from Wicket 1.4 to Wicket 1.5. > One problem we encounter is with Ajax handlers we have that use > AbstractAjaxBehavior.getCallbackUrl to bind serverside code to actions > in the browser. I have been debugging this, and the problem seems to be > that the callback-url puts a renderCount parameter in the url that gets > created. That renderCount however is invalid if you call > AbstractAjaxBehavior.getCallbackUrl during page construction, because in > the render phase the renderCount will be incremented. Effect: a > StalePageException will allways be thrown for such behaviours, because > the renderCount of the behaviour is always invalid. The > StalePageException leads to a new instance of the page, but again with > the same problems for these Ajax behaviours. > > I can probably workaround this by either changing the code to not use > renderCount for these bahviours (not so nice), or to change the > behaviours to move the rendering of the urls from page-construction to > page-render (is going to be a big change). > > My question is: why is renderCount of a page not coupled to the page > construction, instead of to the page render. I believe many wicket pages > use a pattern that initializes their state during constructions, instead > of during render, and this renderCount issue affects all these pages > when they use Ajax. Comments? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
