I've not your experience with this issue, but I'm +1 for discussing alternative solutions which are equally easy to use by framework users. Because I didn't reuse the replace feature so far, may be some one can enlighten me what the use case is. What kind of component or page do you develop where this feature seems to be the obvious solution?
The solution could very well be to "fix" the back button issue with replace(), if that is feasable. Please don't get me wrong. It is not that I want to remove it right away. but I'd like alternative approaches as well. Juergen On Thu, 06 Jan 2005 09:44:22 +0100, Eelco Hillenius <[EMAIL PROTECTED]> 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
