Why do you need numbers to understand that an extra redirect adds to
rendering delay?
On storing values in session, why should I be forced to use a "flash"
technology to handle session. A framework that attempts to be non-intrusive
shouldn't force a session storage strategy because of the way it handles
links! Doing a redirect on every link request is a very intrusive idea. I
hope the Tap developers will re-evaluate this decision in light of the
intrusiveness. As an example, lets say someone wanted to build ajax
functionality on top of this link request. Every ajax request would be
returned as a redirect response. Doesn't sound good.
A framework forcing you to do something because thats how it works - well,
that sounds like something Tap 5 was aiming to avoid. Or am I wrong on that?
----- Original Message -----
From: "Massimo Lusetti" <[EMAIL PROTECTED]>
To: "Tapestry users" <[EMAIL PROTECTED]>
Sent: Friday, April 13, 2007 11:04 AM
Subject: Re: Tapestry 5 Redirects
On 4/13/07, kranga <[EMAIL PROTECTED]> wrote:
1) Log analysis: Your page hit statistics and other log based audit and
troubleshooting activity need to take this into account.
All requests fall in to logs, anyway logs are configurable server
entities and are by no means related to application scope.
2) Extra unwanted delay and traffic in rendering pages.
Do you have numbers?
Storing page state in the session in general is a bad idea. When you have
multiple browser windows connected to the same session, you have complete
chaos.
Someone has already answered your question in this thread.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
