fair enough. -igor
On 9/27/07, Matej Knopp <[EMAIL PROTECTED]> wrote: > > We could do this also in (on)beforeRender, so there wouldn't be > another traversal. > > -Matej > > On 9/27/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > well, what if instead of detecting this on urlfor call you simply > traverse > > the object graph and see if any components implement the request > listener > > interface, and if they do then the page is stateful. so you basically > > measure a potential for the urlfor call... > > > > -igor > > > > > > On 9/27/07, Matej Knopp <[EMAIL PROTECTED]> wrote: > > > > > > Hi all, > > > > > > we have a problem currently. We have a situation, when session is > > > bound in the middle of page rendering. That causes problems with > > > appending session id to URL. > > > > > > Let's have a situation like this: > > > Page with 1 bookmarkable link and one listener interface link. This is > > > the first page rendered, session is not bound yet. > > > > > > When the bookmarkable link is being rendered, the container doesn't > > > append session id to it, because the session is not bound yet. It's > > > bound only when the listener interface link is being rendered, as at > > > that point wicket knows that the page is stateful. So on rendered > > > page, the first bookmarkable link is without session id. > > > > > > I think the proper solution would be doing a bit of less magic - each > > > component should report it's statefullness even without rendering the > > > URL, so we should be a able to determine if page is statefull after > > > beforeRendere, before the actual rendering. So the session could be > > > bound properly and all links on page would contain session Id. > > > > > > -Matej > > > > > >
