<br><br><div class="gmail_quote">On Tue, Jul 5, 2011 at 4:19 AM, Carl Gundel <span dir="ltr"><<a href="mailto:carlg@libertybasic.com">carlg@libertybasic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div class="im"><div><br></div><div><blockquote type="cite"><div>Hi Carl,<br><br>How would you like Seaside to handle it?<br><br>Is there a difference between this case and clicking on the link,<br>
waiting for the page to load, hitting the back button, and then<br>clicking on a different link?<br><br>Julian</div></blockquote><br></div></div>Hey Julian,<div><br></div><div>Since Seaside claims to insulate the programmer from such things, it should have some mechanism to deal with this. I recognize that this is a difficult problem, but if it can be solved nicely in the Seaside framework that would be great.</div>
<div><br></div><div>What happens is that if the connection is slow (or if my app responds too slowly, but this is not the case here) then it makes sense to be able to declare any action (or all the actions on a page or in an app, or for mobile browsers) as doable just once or maybe doable again after so many milliseconds or seconds. Then at least the developer can address the problem if needed.</div>
<div><br></div><div>I supposed I could implement this myself somehow in my coding style. How would you recommend this best be done?<br></div></div></blockquote><div><br>It's not so much that it's hard technically, it's that it's hard semantically. It's hard to even decide for one's *own* application what should happen when a user hits the back button (which, as I said, is more or less the same as clicking quickly on two links on the page). It near on impossible to make this decision in a way that's useful across applications.<br>
<br>But as you say, the tools should be there to make it possible for application developers to make the decisions they want. We'd be open to suggestions on how you think such an API should behave.<br><br>Probably the simplest existing approach would be to subclass WAActionPhaseContinuation and modify it so that it only allows itself to be invoked once. You can configure your application to use that subclass instead of the default. Beyond that, if you wanted finer control, you could look at having one-shot callbacks but I think that would be harder to implement at the moment and I'm not sure they'd be as easy to use with the standard canvas renderer.<br>
<br>Julian<br></div></div>