Hello, > Further, on a page that loads slowly (one that has a large number of > external scripts, is accessed via a slow-bandwidth pipe, or has a > very complex layout), this means that JavaScript event handlers are > not wired up until all JavaScript has been downloaded and parsed. The > end result it that you can "outrace" Tapestry, click a link that > should update a zone and get incorrect behavior or even a runtime > exception. I actually see this when using Formo's time-tracking > application from home through a slow pipe, exacerbated by HTTPS, where > I get the error that "Block is not a valid response type". What should > have been an Ajax request was processed instead as a traditional page > render request, because the JavaScript was not ready.
For this problem, doesn't the solution is server side ? I mean, if the (non-XHR) request return a Block, it's an error in T5, and all in all, there is no gracefull degradation. The server code should always distinguish between XHR events and normal requests, and return accordingly. Or perhaps it's a case of leaky abstraction : event handlers for normal requests and for XHR one's might be actually different beasts (onXhrAction / onAction ). I remember that there was several threads on that subject, especially this one : http://markmail.org/thread/ho3nla6eciyupcah Francois --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
