On Thursday 15 June 2006 00:07, Matt Goodall wrote: > I suspect it's because when SecondPage sees the request was POST'ed and > assumes it's a form POST. Processing the POST will re-find the > FirstPage's form and processes it again which returns a SecondPage, etc.
Thanks for taking the time to look at this, Matt. > Even if SecondPage was rendered correctly after submitting FirstPage, I > think Formal would have a hard time finding SecondPage's form because > the URL would resolve to a FirstPage resource. Yes, I was fearing I was going to hit that problem sooner or later. I guess I was hoping that there was some Deep Magic under the hood that would deal with the URL mapping (maybe some onsubmit Javascript :-) ) > The way I've done this sort of thing is to make FirstPage HTTP redirect > to another URL to display SecondPage, passing data from FirstPage to > SecondPage using request args. (Hint: return a nevow.url.URL instance > from FirstPage's form's submit method.) > > If there's a lot of data to pass around you might need to resort to > sessions. Yucky but, hey, it's the web. Hmm. I've got the URL redirect working, but the data can potentially be too much for a request, so I guess it's sessions. I do actually have a session enabled, as everything is wrapped up inside a portal/guard/SessionWrapper thingie, so it's not a huge deal. However ... that gets me thinking. The next step is basically, "here are the things that matched your criteria; select one or more of them so that I can do something with them", so it seems silly to send them to the browser only to have the browser send them right back again. Additionally, this *isn't* really 'client state', as the intermediate search results aren't persisted beyond the next form (the user's choice from the second form, however, is), nor is it 'privileged data', since anyone who has sufficient permissions to access the first form can find the same search results themselves. Given that this is Twisted, and we don't have threading issues to deal with, is it unfeasibly evil and sinful to pass a handle (e.g. the base64 representation of the original search string) as a request argument to the client and store the 'real' results server-side, to be retrieved while rendering the next form? In other words, I'd end up using sessions for the Important Stuff (e.g. client state) but not use sessions for stuff that doesn't matter. Is this a good application of Laziness, Impatience and Hubris, or is it just a recipe for disaster? :-) Cheers, Ricky P.S. Apologies if I've broken list threading ... kmail doesn't seem to like me using "Reply To Mailing List", so I've just done "Reply To All", hoping that the Message-IDs work. I know that people get religious about their message threading *grin*. _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
