But isn't redirect-on-render what you always want for non-BookmarkablePages? That is, you don't want the user going back, right? If non-BookmarkablePages are the default then redirect should be on by default as well.
Gili
Christopher Turner wrote:
I'm certainly +1 for making the default to NOT redirect. It's certainly more efficient and makes clustering much simpler.
However, before we can do this I think we need to make sure that we have a transparent way of being able to differentiate between a user clicking a link / submitting a form for the first time and them invoking the same request because they hit the refresh button (for which we should just re-render the page).
I wonder if this goes back to needing some kind of render count? So we have version that keeps track of when a page's component structure or model changes and render count which stops double submits from occurring. Or can we do this all with just the one version count value?
Regards, Chris
>
> The more I think about it, the more I'm getting convinced that
> redirecting by default is not the best default.
>
> What about making this *not* the default, but - ofcourse -
> still support
> it the way it is?
>
> Btw, when I was new with Wicket, setRedirect puzzled me; it was not
> immediately clear what would happen when I called that. How about
> 'setRenderAsRedirect' or something similar?
>
> Eelco
>
>
> Christopher Turner wrote:
>
> > The main drawback of option 2 is that it doesn't work in a
> round-robin
> > clustered environment when the 'logical' request spans more
> than one
> > physical request and physical requests are handled by different
> > servers in the cluster.
> >
> > I don't think that this is necessarily a problem provided that:
> > a) We make it very clear that the behaviour in a clustered
> environment
> > is different than a non-clustered environment AND
> >
> > b) The clustered application developer has enough hooks into the
> > 'logical' request such that they can pull down objects (such as the
> > hibernate session) at the end of one physical request and recreate
> > them at the start of the next physical request.
> >
> > Regards,
> > Chris
> >
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from
> real users. Discover which products truly live up to the
> hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396 <http://ads.osdn.com/?ad_id=6595&alloc_id=14396>> &op=click
>
> _______________________________________________
>
> Wicket-develop mailing list [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
