yeah, this was the other reason i didn't like setParent.  it's just 
so useful sometimes.  

one trick you can use sometimes is to /hide/ a component or panel or
whatever.  then the back button should work fine.  it's just when you
alter the components that wicket can't track things.

On Thu, 6 Jan 2005, Eelco Hillenius wrote:

> And that respect... we might want to re-consider the replace method. 
> Since I use replacing components (for tab-like behaviour), I have back 
> button problems all of the time.
> 
> Eelco
> 
> Eelco Hillenius wrote:
> 
> > Yes, Juergen you are right that this is the case. However, this 
> > doesn't only happen when just 'replacing' a component, but will happen 
> > everywhere where you invalidate a model (and remove all components) 
> > and re-add the components.
> >
> > Eelco
> >
> > Juergen Donnerstag wrote:
> >
> >> Johan,
> >>
> >> I tried to reproduce it with the "old" core, especially as I didn't
> >> experience any such problems so far. Not even with a stress test tool
> >> which siimulates plenty of clients working simultaneously. But if I
> >> understand you correct, that is not the use case, because it doesn't
> >> simulate a client refreshing the current multiple times short
> >> sequence. Thus I did what you suggested. I pushed the f5 key for 30
> >> seconds (not releasing it for that time) and saw the requests arriving
> >> at the server and being handled by Wicket. But still no exception. And
> >> I choose one of the displaytag examples with plenty of planels,
> >> border, ListViews etc. I tried several of the other examples. Still no
> >> error.except a SocketException: Connection reset by peer. But on the
> >> client side, everything was fine.
> >>
> >> I recall from mem that Jon predicted such errors, if we allow for
> >> replaceing parents. Are you sure, the cause of the problem is not with
> >> replacing/removing the parent?
> >>
> >> The reason why I'm asking. Are we 100% sure that synchronizing the
> >> render process on the session object does not unneccessarily block
> >> requests?
> >>
> >> Juergen
> >>
> >> On Wed, 05 Jan 2005 15:31:24 +0100, Johan Compagner 
> >> <[EMAIL PROTECTED]> wrote:
> >>  
> >>
> >>> I just checked in a fix that Wicket only handles one request per 
> >>> session
> >>> at once.
> >>>
> >>> There where a lot of problems when we don't do that. Strange markup
> >>> errors, Or components
> >>> that where didn't have a page anymore (removed from the parent) while
> >>> they where rendering!
> >>>
> >>> This all happens when you for example pressed f5 (refrehs) in the
> >>> browser a few times quick after each other.
> >>> Because then on the serverside the same page or components where
> >>> handled/rendered at the same time. Then
> >>> they would use the markupstream for a container panel at the sametime.
> >>> This ofcourse is wrong because
> >>> thread1 could be in place X and thread2 at place Y.
> >>>
> >>> I couldn't think about a better solution then to synch over the session
> >>> in the HttRequestCycle.handleRender() method.
> >>> because callComponentListener() and page.render() needs to be 
> >>> synched at
> >>> runned as a atomic operation.
> >>>
> >>> johan
> >>>
> >>> -------------------------------------------------------
> >>> The SF.Net email is sponsored by: Beat the post-holiday blues
> >>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> >>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> >>> _______________________________________________
> >>> Wicket-develop mailing list
> >>> [email protected]
> >>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >>>
> >>>   
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> The SF.Net email is sponsored by: Beat the post-holiday blues
> >> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> >> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> >> _______________________________________________
> >> Wicket-develop mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >>  
> >>
> >
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by: Beat the post-holiday blues
> > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> > _______________________________________________
> > Wicket-develop mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
> 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Wicket-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> 



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop

Reply via email to