Forum OpenACS Development: Issues with redirecting to /register with big forms

I have a huge form (done with list-builder).  Not just your average sorta-big form, this sucker is giant.  Something to the tune of 20-100 text fields, each potentially containing 20 0 chars (although some will be empty), and about 3x that in shorter fields, check boxes, etc.  This form lives in a package/www/admin directory.

Doing the form submit with GET didn't work in IE (6 with SP2), so I switched it over to POST.  Now everything is wonderful, except:

Sometimes it takes an hour to input the data for this monster form.  Problem is that the site parameters have logins timing out at 15 minutes (this makes sense, since many students accessing the site will be doing so from shared computers).  So there's a decent chance of the person doing the input on the monster form getting logged out before he's completed it.  The problem is that the redirect to login results in the monster form post getting turned into a GET, with return_url=something-about-a-million-lines long.  That GET is too long, so when the user hits submit from the login page, the browser throws an error.  (Happens in IE and Mozilla both, although the exact symptoms are slightly different.)  Depending on browser settings, this can mean an hour's work down the tubes.

Any suggestions?  I've thought about doing a javascript popup (a la online banking) when the session is close to timeout, but I'd rather not be reliant on managing to get a popup past someone's strict browser settings.


Posted by Jade Rubick on
I have a similar issue I've been thinking about, where I'm sending lots of data from page to page.

One possible solution would be to use nsv_arrays. It's kind of a weird way to do things, I guess, but in my case (where I'm not using ad_form, and I actually am sending a lot of arrays between pages), it might make sense.

Someone mentioned internal redirects, but I'm not really sure how those work.

Posted by David Walker on
I like to break down monster forms into smaller forms where page 1 submits to page 2 and hides its input in hidden fields.  Each individual page takes less time to fill out and the final submit would be processed the same way you do it now.

Another option is a hidden frame that refreshes the session while they are filling out this form.

Option 3 is to either hack or brilliantly code something together that sources the submit page from the login submit page.  (the same idea as the internal redirect.  if there is internal redirect code out there that would most likely be preferred)

Posted by russ m on
I've just finished putting together a progress display page for a couple of long-running operations in our application, and I think a similar approach could work for you.

We do a bunch of server-side image processing in some situations, which can take quite a while. The page that gets submitted to forks off a background thread with ns_thread begindetached and then redirects to a progress page that refreshes itself every 30 seconds. The background thread communicates with the progress page through an nsv that's keyed by task_id, updating several progress stats, and the progress page tells the user where the process is up to. When the process is finished the progress page sees this in the nsv structure and presents a "continue" link to the next step in the process.

ideally, I'd like to generalise this to a dropin replacement for the "waiting" page used by the package installer...

Posted by russ m on
D'OH! I just realised you're seeing this timeout while they're filling in the form, not while it's being processed... in which case my suggestion is pointless...

perhaps an iframe that refershes itself to keep the session logged in?

Posted by Cathy Sarisky on
David, I appreciate the suggestions.  I have thought about breaking this form into pieces (and I actually could process each piece separately rather than using hidden variables), but unfortunately some of the logical pieces are likely _still_ too big for completion within 15 minutes, and too long to survive a redirect.  Since this form is used by an instructor to mark student grades on submitted short essays, there's also a pretty good chance that a student will come in for help during a grading session, causing further delays before form submission.

Although the datamodel involved would allow me to break the form up to the point that it survives a redirect, it would be significantly more of a pain for the end-user.

My stop-gap solution for this problem has been to open a new window when submitting the form.  If the instructor is still logged in, great.  If not, the instructor can use the new window to log in, then hit submit again on the original form (which retains the data this way).  Seriously kludgy, but at least we're not losing input. :(

Cathy, does your huge form submit work with GET in any browser? My guess is no. AOLserver 3.x had a maximum URL length it will accept from the client, and I believe AOLserver 4.x works exactly the same way. If the GET request is longer than the max, it will be silently truncated. Last time I checked, this limit defaulted to 8192 bytes. You can change it like this:
ns_section ns/server/$server_name
maxline [expr {8192 * 4}]
AFAIK AOLserver provides no notification that an incoming GET request was truncated. If you need to know that, one kludgy but very simple way is to put some sort of "&end=1" variable last on the URL, and check in your processing that it is in fact still present.