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? >
