[Twisted-web] Cascading forms in formal (example code included)

Ricky Iacovou 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 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*.



More information about the Twisted-web mailing list