No, redirect-on-render is an anti-pattern that was designed to get over
a weakness in the HTTP protocol. It is rather inefficient as it involves
two round trips from the browser to the server. What you ideally want to
achieve is something that APPEARS to be redirect-on-render but does so
with just one request. E.g. the first request handles the event AND
renders but subsequent requests using exactly the same URL and request
parameters are treated as re-render requests (except for bookmarkable
pages - because these are ALWAYS invoked with exactly the same URL).
regards,.
Chris
Gili wrote:
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
-------------------------------------------------------
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
