[Twisted-web] Cascading forms in formal (example code included)
iacovou at gmail.com
Fri Jun 16 07:18:05 CDT 2006
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 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
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
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? :-)
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
More information about the Twisted-web