Hi,<div><br></div><div>In RESTful applications which also generate continuation key (_k) links a problem can arise if you open multiple tabs all sharing the same session. To illustrate:</div><div>1) Enable cookies for <a href="http://localhost:8080/examples/counter" target="_blank">http://localhost:8080/examples/counter</a>. </div>
<div>2) Open the counter and increment the value. </div><div>3) Open <a href="http://localhost:8080/examples/counter" target="_blank">http://localhost:8080/examples/counter</a> in a new tab and decrement the counter. </div>
<div>4) Return to the first counter and increment the value - you will see "-1" rather then "2" !</div>
<div><br></div><div>What I think is happening:</div><div><div>If Seaside finds a session but there is no continuation key (_k) then WASession>>#handleFiltered: calls WARenderLoopMain>>#start which in turn creates a new root presenter and calls #initialRequest on the presenter. When the second tab is opened a new WACounter is created and stored in the session's #presenter property. When you return to the first tab, the callback is executed on the first counter, but the second counter is rendered.</div>
</div><div><br></div><div>Ideas for possible fixes:</div><div><br></div><div>* I thought that #presenter was backtracked so don't understand why the original counter #presenter isn't restored for the callback. If the presenter was backtracked correctly then the counter example should work as anticipated.... however:</div>
<div>* in Pier (and potentially other RESTful apps) you don't want to create a new presenter for every RESTful call within an active session. If you don't create a new presenter then #initialRequest currently won't be called, which then won't allow your RESTful app to derive state from the url. If Seaside is modified to call #initialRequest do you need to differentiate between a call on a newly created session and one on an existing session? You could differentiate with a call to a new method on WAPresenter, pass in a flag to #initialRequest, or set a WARequestContext property to indicate a new session had been created. What to do with backtracked state. Do you nil all state before handling the request, restore state from a stored "initial value" snapshot or just use the state of the components from their last handled state?</div>
<div><br></div><div>I bought this issue up before [1], but didn't pursue it as I was struggling to understand the issues and ran out of time. Julian responded to my previous email when I was proposing a problematic fix with:</div>
<div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">I'm not sure it's a good fix in the general case. </span>If you don't have a <br>
continuation key, you shouldn't (by definition) have any existing<br>(backtracked) state. Relying on the root presenter currently in the<br>Session is problematic since that value is backtracked for each<br>request; you'll simply get whichever root happened to be used by<br>
whatever request was la<span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">st handled by that session. If you don't happen<br></span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">to be ever changing the root, then it may well be what you want, but<br>
</span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">it's not right in the general case.</span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><br>
</span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">Incidentally, this also touches on the flaw I was discussing the other<br></span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">week with our snapshots: because w</span>e have no continuation key, w<font class="Apple-style-span" color="#222222" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse:collapse">e<br>
</span></font><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">really ought to nil out any backtracked data before processing the<br></span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">request (at least that way we have a consistent state while handling<br>
</span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">the request). We don't run into the problem with the root presenter<br></span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">because #start reinitializes it, but for other backtracked state,<br>
</span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">you'd just get random stuff in there based on the last-handled<br></span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">request.</span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><br>
</span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">A more appropriate general fix (at least in this case) could be to<br></span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">take the last-use</span>d continuation and apply its state before handling a<br>
request with no _k. However, we don't alway<font class="Apple-style-span" color="#222222" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse:collapse">s know the last-used<br></span></font><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">(depending on the caching mechanism in place) and I'm not convinced<br>
</span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">that is actually always what people want. I still feel pretty<br></span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">confident that the "right" semantics of an Application/Session request<br>
</span><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">with no _k is to start a new main/render-loop.</span></blockquote><div><br></div><div>
Certainly for Pier as it is currently designed I don't think that creating a new render-loop for session requests with the _k is the right thing to do, as it created a new root #presenter. I think ideally Seaside would for existing session with no _k </div>
<div><br></div><div>1) Keep the existing #presenter</div><div>2) call #initialRequest with a flag to indicate that a new session hadn't been created.</div><div>3) restore the state to an "initial render state" which is snapshotted (?) when the initial render occurs on a new session.</div>
<div><br></div><div>Thoughts</div><div><br></div><div>Nick</div><div><br></div><div><br></div><div>[1] <a href="http://forum.world.st/sessions-continuation-keys-restful-urls-and-component-state-td3532861.html">http://forum.world.st/sessions-continuation-keys-restful-urls-and-component-state-td3532861.html</a></div>
<div><br></div><div><br></div>
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>If each tabs starts with a RESTful url then a new presenter will be created. </div>