yes but people don't just navigate by submitting forms. they also navigate by clicking links. The only way to keep a conversation would be to store a token in request.args(0) and keep it there in all links. Still the conversation is fragile and ends if the user types in a url without the token.
On Jun 11, 12:04 am, Thadeus Burgess <thade...@thadeusb.com> wrote: > That is where the hidden input field with a custom hash comes into > play I think....? > > -- > Thadeus > > On Fri, Jun 11, 2010 at 12:00 AM, mdipierro <mdipie...@cs.depaul.edu> wrote: > > The only issue is that if you have two browser windows open I do not > > know of a mechanism to identify from which of the two windows a > > request arrives since the cookies are the same. > > > On Jun 10, 11:39 pm, pierreth <pierre.thibau...@gmail.com> wrote: > >> On 10 juin, 19:14, mdipierro <mdipie...@cs.depaul.edu> wrote: > > >> > Interesting. How do you think this can be implemented? > > >> Well, before thinking about the implementation, we must understand the > >> concepts involved. > > >> So let's start with the idea of scope. The scope defines the time a > >> peace of information is kept. Information in application memory is > >> present a certain scope. From the shortest to the longest, scopes form > >> a hierarchy. One scope is included in the life time of another. We may > >> have: > > >> - Request scope (exists the time it takes to process the request) > >> - Conversation scope (the time of a conservation) > >> - Session scope (as we already know) > >> - Application scope (from the server start up to its shutdown) > >> - Business process scope (scope usually involving many actors and that > >> can last for many months, this state has to be saved and restored > >> between server shutdowns) > > >> The conversation scope deserves more explanation. This is the scope to > >> use for example when a user wants to reserve a hotel room. The user > >> goes through a set of pages to do its reservation (he can also use the > >> back button if he change his mind). He can open a new window and do > >> another reservation in parallel. The application keep a different > >> state for each window. This is what we call a conversation. > > >> In the application, we need an object to read and write in these > >> scopes. Let's called it the 'scope resolver' or 'resolver' for short. > >> Instead of using the session, we use the resolver. The resolver looks > >> for a property in the shortest long living scope to find the value of > >> a property. If it does not find the value at one scope, it looks at > >> the next longer living scope. It continues like that up the longest > >> scope. If nothing is found in the whole lookup process, it returns > >> 'None'. > > >> To begin and end scoping processes, I think we can use decorators just > >> like Java uses annotations. We also have to find a way to add a hidden > >> field in the forms to identify them with a specific conversation. > > >> All of this was implemented in Java using the interceptor pattern. I > >> know that Web2py has the concept of plug-in (I am new to Web2py). Is > >> it possible to implement all this without modifying Web2py? It could a > >> great occasion to improve the design of the framework if it is not the > >> case. > > >> We have a great example with JBoss Seam. Spring Webflow could be > >> inspiring too. > > >> So before going in the details, what do think about this idea?
