Perrin Harkins writes: > breaks caused by the request model of HTTP, and that's what I was commenting > on. You're talking about a way to preserve data across multiple page > requests.
FormContext maintains an "HTTP call stack", which holds the parameters (form, query, path_info) and return address (calling Task). Tasks are work units (server subroutines). URIs are UI elements, which is why we don't store them in the FormContext. > If I understand your FormContext approach correctly, you are storing the > state of the current application in URLs or hidden fields. This is what we > used at eToys as well, and I think it's a pretty common solution. FormContext is a formal stack architecture. The callee can reach into the stack to get or to modify caller's form data as in the ShippingAddressForm case. It also handles the case of a call from a non-form Task, e.g. if you bookmark your private home page on a site, the LoginForm requires context so it knows where to return to after successful authentication. The Login task needs no knowledge of who called it; it just returns to the Task specified in its FormContext. If there is no FormContext, it returns to its "next" task specified by the state machine. The reason I brought up sessions is that the above mechanism wouldn't work if there were sessions. Sessions might time out or go away for bookmarked pages. FormContext survives server restarts and renaming of the calling page's URI. Rob
