You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Stefan Simik <st...@gmail.com> on 2007/11/22 18:57:57 UTC
Rendering strategies question
Hello Wicketeers,
I prepare report about rendering strategies (for studying community in our
company) and conceptually I understand all the things, but I have one
question, that I cannot answer.
The default rendering strategy is RENDER_TO_BUFFER, because it solves both
problems of
two previous strategies:
1. no double submit problem
2. no potential problems with double attaching/detaching models
But in my mind, I have problem:
When some aplication has 90% of pages, that are only for viewing, and 10% of
pages, that submit form,
then I see, that for 90% of the view pages is the redirect not useful. For
these 90% pages would be sufficient only ONE_PASS_RENDER strategy, because
there is no need for redirect from my point of view.
Only 10% of pages takes advantage from redirecting. Does'nt it make 90% of
needless redirects ?
Is it not possible tu use REDIRECT_TO_BUFFER strategy only for POST request,
and for all GET request
respond with ONE_PASS_RENDER ? But in WicketFilter all POST's call GET, so I
think it's not possible.
Is there anything I forgot to think about ?
Thank you for you answer
Stefan Simik
--
View this message in context: http://www.nabble.com/Rendering-strategies-question-tf4857740.html#a13900891
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Rendering strategies question
Posted by Johan Compagner <jc...@gmail.com>.
if you dont want redirect call: setRedirect(false)
johan
On Nov 22, 2007 6:57 PM, Stefan Simik <st...@gmail.com> wrote:
>
> Hello Wicketeers,
>
> I prepare report about rendering strategies (for studying community in our
> company) and conceptually I understand all the things, but I have one
> question, that I cannot answer.
>
> The default rendering strategy is RENDER_TO_BUFFER, because it solves both
> problems of
> two previous strategies:
> 1. no double submit problem
> 2. no potential problems with double attaching/detaching models
>
> But in my mind, I have problem:
> When some aplication has 90% of pages, that are only for viewing, and 10%
> of
> pages, that submit form,
> then I see, that for 90% of the view pages is the redirect not useful. For
> these 90% pages would be sufficient only ONE_PASS_RENDER strategy, because
> there is no need for redirect from my point of view.
> Only 10% of pages takes advantage from redirecting. Does'nt it make 90%
> of
> needless redirects ?
>
> Is it not possible tu use REDIRECT_TO_BUFFER strategy only for POST
> request,
> and for all GET request
> respond with ONE_PASS_RENDER ? But in WicketFilter all POST's call GET, so
> I
> think it's not possible.
>
> Is there anything I forgot to think about ?
>
> Thank you for you answer
>
> Stefan Simik
>
>
>
>
> --
> View this message in context:
> http://www.nabble.com/Rendering-strategies-question-tf4857740.html#a13900891
> Sent from the Wicket - User mailing list archive at Nabble.com<http://nabble.com/>
> .
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Rendering strategies question
Posted by Eelco Hillenius <ee...@gmail.com>.
> mhmm, now I got it...
> In other frameworks and also in Wicket it's common to use GET request for
> doing some action on the server ( for example Link#onClick(...) ), so it's
> generally useful concept. I didn't see it from this point of view before.
Yeah. Like I said, officially GET requests should be idempotent. And
that's fine when you talk about documents but hardly makes sense when
you think about applications. Even if you avoid state changing things
like deleting records with links, you still have to deal with things
like data that might get stale between requests. So personally, I
think the idea of having idompotent web requests as part of user
interfaces is flawed to start with.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Rendering strategies question
Posted by Stefan Simik <st...@gmail.com>.
mhmm, now I got it...
In other frameworks and also in Wicket it's common to use GET request for
doing some action on the server ( for example Link#onClick(...) ), so it's
generally useful concept. I didn't see it from this point of view before.
Thank you both boys :)
Stefan Simik
--
View this message in context: http://www.nabble.com/Rendering-strategies-question-tf4857740.html#a13904939
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Rendering strategies question
Posted by Eelco Hillenius <ee...@gmail.com>.
On Nov 22, 2007 11:46 AM, Martijn Dashorst <ma...@gmail.com> wrote:
> Wicket will redirect all event listeners so you don't get double clicks as
> well.
Of course, GET requests *should* be idempotent, in which case we would
never need this pattern. However, in practice, with whatever framework
people are using, GETs often are not implemented being idempotent, so
our extra protection makes sense even for GETs.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Rendering strategies question
Posted by Martijn Dashorst <ma...@gmail.com>.
Wicket will redirect all event listeners so you don't get double clicks as
well.
For instance a link to edit some item takes you to an edit page. If you do a
onepass render, the event listener will be called each time the user
refreshes the edit page. This means that the edit page is created each time
and any operations that are part of the event listener will be executed as
well.
However with the redirect to buffer, the user is redirected to a stable URL,
and remains on the edit page. When he refreshes the page, the edit page is
fetched from the page store and rendered again. No event listeners are
involved here.
Martijn
On Nov 22, 2007 6:57 PM, Stefan Simik <st...@gmail.com> wrote:
>
> Hello Wicketeers,
>
> I prepare report about rendering strategies (for studying community in our
> company) and conceptually I understand all the things, but I have one
> question, that I cannot answer.
>
> The default rendering strategy is RENDER_TO_BUFFER, because it solves both
> problems of
> two previous strategies:
> 1. no double submit problem
> 2. no potential problems with double attaching/detaching models
>
> But in my mind, I have problem:
> When some aplication has 90% of pages, that are only for viewing, and 10%
> of
> pages, that submit form,
> then I see, that for 90% of the view pages is the redirect not useful. For
> these 90% pages would be sufficient only ONE_PASS_RENDER strategy, because
> there is no need for redirect from my point of view.
> Only 10% of pages takes advantage from redirecting. Does'nt it make 90%
> of
> needless redirects ?
>
> Is it not possible tu use REDIRECT_TO_BUFFER strategy only for POST
> request,
> and for all GET request
> respond with ONE_PASS_RENDER ? But in WicketFilter all POST's call GET, so
> I
> think it's not possible.
>
> Is there anything I forgot to think about ?
>
> Thank you for you answer
>
> Stefan Simik
>
>
>
>
> --
> View this message in context:
> http://www.nabble.com/Rendering-strategies-question-tf4857740.html#a13900891
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-rc1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/