[Tutor] Web app in Python: alternatives to CGI?

Alan Gauld alan.gauld at blueyonder.co.uk
Sun Apr 18 03:25:21 EDT 2004


> Well, it's submit the form, capture the data; based on the data,
figure
> out what additional data is needed, and then submit another form and
> capture the data; based on that data, figure out what additional
data is
> required, etc.

Sure, but usually by thinking through the logic you can collapse
it to two forms max. And there is nothing more annoying than an
application that requires you to go through a heap of little
forms so it helps your user too.

For example its usually better to capture some irrelevant data
than to present more forms...

> For example, if the work was published prior to 1978, the date of
the
> author's death is not needed, so I don't want to ask it.  Similarly,
if
> the work was created after 1977, the date of publication is
irrelevant, so
> I don't want to ask.
>
> So I'll ask something like:
>
>   Was the work:
>    () published in 1977 or earlier;
>    () created in 1978 or later;
>    () created in 1977 or earlier, but not published prior to 1978;
>    () don't know.
>
> Then if the user selected "published in 1977 or earlier", the next
screen
> would ask "what's the date of publication"; but if he sleected
"created in
> 1978 or later," the next screen would ask "is the author still
alive"; if
> the third, it would go on to ask if the work was ever published.

Or just combine all that in one screen.

Actually there's no harm in just getting them to fill in the
date regardless - then you can figure out when it was published
and which rules apply - much less hassle for the user.
Especially if you use a drop down list which includes
a "Not Published" option... In fact looking at your list above
I'd suggest you jave two drop down lists, one for creation date
and one for published date. Then you can figure out the right
permutation easily and the user

And ask if the author is still alive regardless of date.
And if dead the date of death.
You can use GUI design tricks to break the form into visual
sections too.

That is much faster for the user (no network waits), and
easier for you to process.

> So it's not just one CGI process.  I need to save status from call
to
> call; cookies or something I guess.  That's what I meant by

Usually you just pass a hidden data member as part of the form data
which is some kind of encoded string capturing all data up till now.

> > And the country... If you are putting it on the web you may
> > have users from many countries accessing it. Something to
> > consider - even if its only with a US only disclaimer...
>
> This is US only.

Yes, but if its on the internet (as opposed to the intranet)
other countries will access it. One of my pet peeves is the
number of US sites that assume that only US folks will use them,
but don't tell you that their data is US specific! And I don't
know why, but it seems to be only US sites that do this!

In other words its not a matter of who the targetted audience is
but where the site is hosted. If its an intranet then US only
is fine, if its on the internet it should cater for non US
users too - at least by saying its only intended for the US!

Alan G.




More information about the Tutor mailing list