[Tutor] Python/CGI question: multiple-screen interview

Tim Johnson tim@johnsons-web.com
Sat Apr 26 18:34:01 2003

Hi Terry:
    Disclaimer - I pretty much 'earn my bread' with CGI,
but I'm only slowly converting to python:

* Terry Carroll <carroll@tjc.com> [030426 11:28]:
> This is probably as much a CGI question as Python, but I hope it's not too 
> off-topic.
> I want to write a Python web application (at this point, I'm thinking CGI) 
> that asks the user a series of questions.  I don't want to do a one-page 
> form, because a lot of questions will be inapplicable depending on earlier 
> answers.[1]
> This seems to require saving state in some way between invocations.  
> What's the best approach for this?  Cookies?  Something else?
  I am not seeing anything in your plans that couldn't be solved
  simply by posting data forward via. Data entered in on page could
  be posted forward and 'stored' in hidden fields....

> Would you do this as multiple Python CGI programs, one for each set of 
> questions, or a single program that sets up some sort of dialog?
  There is no reason why this couldn't be done with one CGI application,
  really that's kind of up to you, based on the size of the script, etc.

> Finally, am I crazy for planning on doing this as CGI?  Should I be
> thinking of doing it some other way, say as a Java servlet with Jython
> (about which I know nothing)?
  I use MySql a lot, and frequently use mysql to store persistant
  data when it becomes unwieldly to pass around via 'get' or 'post'

  My company's philosophy (and that's just our standard operating
  procedure) is to do as much on the server as possible. We 
  resort to cookies as a last resort and javascript only when
  desired by the client and/or necessary.

  - the *KISS* principle - 

  You've really got a lot of options here - it would help you
  to get 'up to speed' on cgi and find out what it offers
  you..... in my opinion.
> [1] An example may help.  My application is to determine the expiration of 
> a particular work's U.S. copyright.  For works published prior to 1978, 
> this is based on the publication date.  For works created 1978 or later, 
> it's based on the date of the author's death.  So, if the user answers an 
> early question that the work was published in, say, 1964, I don't want to 
> ask if and when the author died; it doesn't matter, and won't affect the 
> outcome.

  .... so you post the copyright forward to another instance, that
  instance (cgi program) grabs the copyright from the cgi content,
  acts based on that date, and stores the date as a hidden field
  so that the user can't change it at this time, and preserves
  for the next posting....

> -- 
> Terry Carroll        |  "To have this rare opportunity
> Santa Clara, CA      |    is a rare opportunity."
> carroll@tjc.com      |    - Houston Rockets' Yao Ming, on being named
> Modell delendus est  |    starting center for the 2003 NBA All-Star Game
> _______________________________________________
> Tutor maillist  -  Tutor@python.org
> http://mail.python.org/mailman/listinfo/tutor

Tim Johnson <tim@johnsons-web.com>