Re: Implication of client side redirect
There is a lot wrong with the current model of the web and the HTTP standard in general requires a major overhall so far as web applications are concerned, but considering this current state we are in, redirect-after-post is a good solution, perhaps not perfect but this is not an ideal world either. Peter - Original Message - From: Dave Greggory davegregg...@yahoo.com To: Tapestry users users@tapestry.apache.org Sent: Thursday, 12 March, 2009 02:23:47 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Implication of client side redirect Yeah, you're right about that. Still I don't like the redirect-after-post for validation failures because it needs the form data to be persisted somehow between the two requests. We can solve it partially by using client-side persistence for simple data, but for complex object hierarchies, there is no way other than to persist to session. Session persistence is not something I'm very crazy about because it tends to introduce a number of problems. For example, if a user opens Item A for editing in one browser tab, then without touching A, opens item B in another browser tab, item B just overwrote item A in session persisted property. So if he goes back to item A and edits and saves it, he will be saving item A content into item B. You can write a lot of hacky/boilerplate code to get around it, but it's not very elegant. Also, if we choose to disable redirect-after-post functionality all together, it makes it very hard to do a number of things in tapestry, I believe Howard warns about doing so here. http://tapestry.apache.org/tapestry5/guide/conf.html - Original Message From: nillehammer tapestry.nilleham...@winfonet.eu To: Tapestry users users@tapestry.apache.org Sent: Wednesday, March 11, 2009 7:44:00 PM Subject: Re: Implication of client side redirect Hi Dave, your message made me doubt and I immediately tried that out (on IE 6 and FF 2). I was not able to reproduce, what you were implying. So I still think that redirect after post solves the problem. Regards nillehammer - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Implication of client side redirect
Thanks Robert. It is defenitly good to know that there is way to turn it off, it keeps my options open. - Original Message From: Robert Zeigler robe...@scazdl.org To: Tapestry users users@tapestry.apache.org Sent: Wednesday, 11 March, 2009 10:04:56 PM Subject: Re: Implication of client side redirect Hi Rajesh, Tapestry follows the redirect after post principle. This has a lot of pros (avoiding double submission of forms, for instance), but if you're really concerned about it, there's a configuration option to turn it off. In org.apache.tapestry5.SymbolConstants: /** * If set to true, then action requests will render a page markup response immediately, rather than sending a * redirect to render the response. */ public static final String SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS = tapestry.suppress-redirect-from-action-requests; Cheers, Robert 11, 2009, at 3/1110:35 AM , rajesh sukumaran wrote: Hi, I am evaluating Tapestry 5.1 to see if I can use it in one of my new projects. I see that Tapestry uses client side redirects to handle response for event requests. Will this not affect the performance of Tapestry applications, especially under high load? Redirects will result in an additional HTTP hit on the server for every event request that is rendered by a different page. Will this not degrade the responsiveness of the web application as the load increase? I would like to know what everyone thinks about this? regards, Rajesh Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org Check out the all-new Messenger 9.0! Go to http://in.messenger.yahoo.com/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Implication of client side redirect
that was interesting read... thanks - Original Message From: manuel aldana ald...@gmx.de To: Tapestry users users@tapestry.apache.org Sent: Wednesday, 11 March, 2009 11:28:53 PM Subject: Re: Implication of client side redirect read this, very interesting: http://www.theserverside.com/tt/articles/article.tss?l=RedirectAfterPost rajesh sukumaran schrieb: Hi, I am evaluating Tapestry 5.1 to see if I can use it in one of my new projects. I see that Tapestry uses client side redirects to handle response for event requests. Will this not affect the performance of Tapestry applications, especially under high load? Redirects will result in an additional HTTP hit on the server for every event request that is rendered by a different page. Will this not degrade the responsiveness of the web application as the load increase? I would like to know what everyone thinks about this? regards, Rajesh Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Implication of client side redirect
Hi Rajesh, Tapestry follows the redirect after post principle. This has a lot of pros (avoiding double submission of forms, for instance), but if you're really concerned about it, there's a configuration option to turn it off. In org.apache.tapestry5.SymbolConstants: /** * If set to true, then action requests will render a page markup response immediately, rather than sending a * redirect to render the response. */ public static final String SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS = tapestry.suppress-redirect-from-action-requests; Cheers, Robert 11, 2009, at 3/1110:35 AM , rajesh sukumaran wrote: Hi, I am evaluating Tapestry 5.1 to see if I can use it in one of my new projects. I see that Tapestry uses client side redirects to handle response for event requests. Will this not affect the performance of Tapestry applications, especially under high load? Redirects will result in an additional HTTP hit on the server for every event request that is rendered by a different page. Will this not degrade the responsiveness of the web application as the load increase? I would like to know what everyone thinks about this? regards, Rajesh Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Implication of client side redirect
read this, very interesting: http://www.theserverside.com/tt/articles/article.tss?l=RedirectAfterPost rajesh sukumaran schrieb: Hi, I am evaluating Tapestry 5.1 to see if I can use it in one of my new projects. I see that Tapestry uses client side redirects to handle response for event requests. Will this not affect the performance of Tapestry applications, especially under high load? Redirects will result in an additional HTTP hit on the server for every event request that is rendered by a different page. Will this not degrade the responsiveness of the web application as the load increase? I would like to know what everyone thinks about this? regards, Rajesh Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Implication of client side redirect
While I highly agree the redirect-after-post pattern is a good practice. It only makes sense in some situations. It makes sense to use it when you're submitting a form and the form submission was successful (ie. Tapestry success event fires). But if validation fails, Tapestry should not be using a redirect to re-show the form with the validation errors. When validation fails, it should use the response for the same request for re-showing the form, it should not be sending a 302. I wish there is a way to disable redirects for validation failures only. - Original Message From: Robert Zeigler robe...@scazdl.org To: Tapestry users users@tapestry.apache.org Sent: Wednesday, March 11, 2009 12:34:56 PM Subject: Re: Implication of client side redirect Hi Rajesh, Tapestry follows the redirect after post principle. This has a lot of pros (avoiding double submission of forms, for instance), but if you're really concerned about it, there's a configuration option to turn it off. In org.apache.tapestry5.SymbolConstants: /** * If set to true, then action requests will render a page markup response immediately, rather than sending a * redirect to render the response. */ public static final String SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS = tapestry.suppress-redirect-from-action-requests; Cheers, Robert 11, 2009, at 3/1110:35 AM , rajesh sukumaran wrote: Hi, I am evaluating Tapestry 5.1 to see if I can use it in one of my new projects. I see that Tapestry uses client side redirects to handle response for event requests. Will this not affect the performance of Tapestry applications, especially under high load? Redirects will result in an additional HTTP hit on the server for every event request that is rendered by a different page. Will this not degrade the responsiveness of the web application as the load increase? I would like to know what everyone thinks about this? regards, Rajesh Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Implication of client side redirect
Part of the driving force here is to have servlet Tapestry and portlet Tapestry (when it arrives) work the same. On Wed, Mar 11, 2009 at 2:03 PM, Dave Greggory davegregg...@yahoo.com wrote: While I highly agree the redirect-after-post pattern is a good practice. It only makes sense in some situations. It makes sense to use it when you're submitting a form and the form submission was successful (ie. Tapestry success event fires). But if validation fails, Tapestry should not be using a redirect to re-show the form with the validation errors. When validation fails, it should use the response for the same request for re-showing the form, it should not be sending a 302. I wish there is a way to disable redirects for validation failures only. - Original Message From: Robert Zeigler robe...@scazdl.org To: Tapestry users users@tapestry.apache.org Sent: Wednesday, March 11, 2009 12:34:56 PM Subject: Re: Implication of client side redirect Hi Rajesh, Tapestry follows the redirect after post principle. This has a lot of pros (avoiding double submission of forms, for instance), but if you're really concerned about it, there's a configuration option to turn it off. In org.apache.tapestry5.SymbolConstants: /** * If set to true, then action requests will render a page markup response immediately, rather than sending a * redirect to render the response. */ public static final String SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS = tapestry.suppress-redirect-from-action-requests; Cheers, Robert 11, 2009, at 3/1110:35 AM , rajesh sukumaran wrote: Hi, I am evaluating Tapestry 5.1 to see if I can use it in one of my new projects. I see that Tapestry uses client side redirects to handle response for event requests. Will this not affect the performance of Tapestry applications, especially under high load? Redirects will result in an additional HTTP hit on the server for every event request that is rendered by a different page. Will this not degrade the responsiveness of the web application as the load increase? I would like to know what everyone thinks about this? regards, Rajesh Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Implication of client side redirect
How does the redirect-after-post mechanism affect a servlet based or portlet based Tapestry system? - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Implication of client side redirect
Hi Dave, I am afraid I disagree with you on this point. Even when validation fails, redirect after post does make sense. Although you're right that double submission is not a problem when validation fails. If you respond directly to a post, the post will get into the browser's history. This is a problem when the browser's back button is used. This would result in the ugly dialogue Do you want to send formdata again... popping up. This can only be avoided by never directly responding to a post-request. Regards, nillehammer Dave Greggory schrieb: While I highly agree the redirect-after-post pattern is a good practice. It only makes sense in some situations. It makes sense to use it when you're submitting a form and the form submission was successful (ie. Tapestry success event fires). But if validation fails, Tapestry should not be using a redirect to re-show the form with the validation errors. When validation fails, it should use the response for the same request for re-showing the form, it should not be sending a 302. I wish there is a way to disable redirects for validation failures only. - Original Message From: Robert Zeigler robe...@scazdl.org To: Tapestry users users@tapestry.apache.org Sent: Wednesday, March 11, 2009 12:34:56 PM Subject: Re: Implication of client side redirect Hi Rajesh, Tapestry follows the redirect after post principle. This has a lot of pros (avoiding double submission of forms, for instance), but if you're really concerned about it, there's a configuration option to turn it off. In org.apache.tapestry5.SymbolConstants: /** * If set to true, then action requests will render a page markup response immediately, rather than sending a * redirect to render the response. */ public static final String SUPPRESS_REDIRECT_FROM_ACTION_REQUESTS = tapestry.suppress-redirect-from-action-requests; Cheers, Robert 11, 2009, at 3/1110:35 AM , rajesh sukumaran wrote: Hi, I am evaluating Tapestry 5.1 to see if I can use it in one of my new projects. I see that Tapestry uses client side redirects to handle response for event requests. Will this not affect the performance of Tapestry applications, especially under high load? Redirects will result in an additional HTTP hit on the server for every event request that is rendered by a different page. Will this not degrade the responsiveness of the web application as the load increase? I would like to know what everyone thinks about this? regards, Rajesh Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- http://www.winfonet.eu - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Implication of client side redirect
Redirect-after-post does not really solve that problem because if you hit Back button twice, you still get the same problem. - Original Message From: nillehammer tapestry.nilleham...@winfonet.eu To: Tapestry users users@tapestry.apache.org Sent: Wednesday, March 11, 2009 7:15:38 PM Subject: Re: Implication of client side redirect Hi Dave, I am afraid I disagree with you on this point. Even when validation fails, redirect after post does make sense. Although you're right that double submission is not a problem when validation fails. If you respond directly to a post, the post will get into the browser's history. This is a problem when the browser's back button is used. This would result in the ugly dialogue Do you want to send formdata again... popping up. This can only be avoided by never directly responding to a post-request. Regards, nillehammer - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Implication of client side redirect
Em Wed, 11 Mar 2009 20:31:30 -0300, Dave Greggory davegregg...@yahoo.com escreveu: Redirect-after-post does not really solve that problem because if you hit Back button twice, you still get the same problem. I disagree. You just have this problem when you submitted a form and returned a page in the same request. With redirect-after-post, POSTs never return pages, and that's exactly what the Firefox (and other browsers, besides Opera, AFAIK) warns. -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Implication of client side redirect
Hi Dave, your message made me doubt and I immediately tried that out (on IE 6 and FF 2). I was not able to reproduce, what you were implying. So I still think that redirect after post solves the problem. Regards nillehammer Dave Greggory schrieb: Redirect-after-post does not really solve that problem because if you hit Back button twice, you still get the same problem. - Original Message From: nillehammer tapestry.nilleham...@winfonet.eu To: Tapestry users users@tapestry.apache.org Sent: Wednesday, March 11, 2009 7:15:38 PM Subject: Re: Implication of client side redirect Hi Dave, I am afraid I disagree with you on this point. Even when validation fails, redirect after post does make sense. Although you're right that double submission is not a problem when validation fails. If you respond directly to a post, the post will get into the browser's history. This is a problem when the browser's back button is used. This would result in the ugly dialogue Do you want to send formdata again... popping up. This can only be avoided by never directly responding to a post-request. Regards, nillehammer - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- http://www.winfonet.eu - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Implication of client side redirect
Yeah, you're right about that. Still I don't like the redirect-after-post for validation failures because it needs the form data to be persisted somehow between the two requests. We can solve it partially by using client-side persistence for simple data, but for complex object hierarchies, there is no way other than to persist to session. Session persistence is not something I'm very crazy about because it tends to introduce a number of problems. For example, if a user opens Item A for editing in one browser tab, then without touching A, opens item B in another browser tab, item B just overwrote item A in session persisted property. So if he goes back to item A and edits and saves it, he will be saving item A content into item B. You can write a lot of hacky/boilerplate code to get around it, but it's not very elegant. Also, if we choose to disable redirect-after-post functionality all together, it makes it very hard to do a number of things in tapestry, I believe Howard warns about doing so here. http://tapestry.apache.org/tapestry5/guide/conf.html - Original Message From: nillehammer tapestry.nilleham...@winfonet.eu To: Tapestry users users@tapestry.apache.org Sent: Wednesday, March 11, 2009 7:44:00 PM Subject: Re: Implication of client side redirect Hi Dave, your message made me doubt and I immediately tried that out (on IE 6 and FF 2). I was not able to reproduce, what you were implying. So I still think that redirect after post solves the problem. Regards nillehammer - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
