<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Aug 17, 2005, at 6:49 PM, Phillip J. Eby wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">That really hasn't been my experience.<SPAN class="Apple-converted-space"> </SPAN>Partly, this is because I tend to use RESTful approaches that put 99% of all statefulness in the browser.<SPAN class="Apple-converted-space"> </SPAN>For example, if I have a multi-page form, I embed all the previous pages' data as hidden fields on the subsequent pages.<SPAN class="Apple-converted-space"> </SPAN>The entire form is processed by a single validation routine, so it doesn't matter what the client sends or in what order, because as soon as all the data is both present and valid, the form is done.<SPAN class="Apple-converted-space"> </SPAN>Similarly, the vast majority of UI flow is easiest to model as URL-per-state, so that the browser is in charge of the flow, and the back button works.</DIV></BLOCKQUOTE></DIV><FONT class="Apple-style-span" color="#0000DD"><BR class="khtml-block-placeholder"></FONT><DIV><FONT class="Apple-style-span" color="#000000">its usually not my experience either, and I have rarely written any kind of app that uses sessions. 99% of everything I've done relies upon browser state as well. although despite my being there "when the web was won" in 95, I am hesitant to call myself a RESTFUL developer...to me, REST seems to be taking some common sense ideas and turning them into some kind of rigid ideological crusade, which is just as bad as all the other ideological crusades we "web winners" had to fight with IIS and active server pages, EJB, UML, SOAP, etc.</FONT></DIV><DIV><FONT class="Apple-style-span" color="#000000"><BR class="khtml-block-placeholder"></FONT></DIV><DIV><FONT class="Apple-style-span" color="#000000">the app i work on is a document mangement system where users have to edit large sets of fields, and do alot of reloading in order to load in new sections of the document or save various subsets of data. Its been running and being expanded regularly for several years, and it does it all using client-state only, but it has begun to outgrow that approach; it would be much more succinctly written storing the user's current workspace within something that at least conceptually is a "session". it would also allow popups, IFRAMES and future Ajax controls to all access the same user-workspace without having to perform vast Javascript gymnastics (which it does right now).</FONT></DIV><DIV><FONT class="Apple-style-span" color="#000000"><BR class="khtml-block-placeholder"></FONT></DIV><DIV><FONT class="Apple-style-span" color="#000000">a document editing system is also a good example of where objects need to be persisted in two different scopes, i.e. a session-scope as well as a permanent scope. I dont really think a session has anything to do with a "physical three-tiered model". physically, it can be whereever you want. i just think its advantageous from a conceptual point of view.</FONT></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV></BODY></HTML>