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
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: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>