VanL,
I'm coming from a disparate background, and only recently started working
with quixote myself, and I had this concern also. I learned early on that
quixote had Form support built in (which has recently been overhauled to
eliminate dependency on PTL), but I wasn't sure I liked it's approach. I
have since written a couple of apps that were really just exercises for
getting familiar with quixote's approach, and on my second one, after facing
the problems you've described, decided to take another look at the Form
support provided by quixote.
It uses an approach similar, but not identical to the 1st option you
describe. The same URL is used for rendering the form as for processing
(and validating) the form, and any needed redirects happen after processing.
The folks who put it together did a bang up job of factoring code down as
much as possible, so it's easy to subclass it once to fit your approach, and
then subclass that version into each form instance you need. Because of the
level of factoring, you can override just the parts you need to override,
without having huge amounts of code copied from form.py into your custom
version. Mine is only about 60 lines long, and I've changed a bit about
error display, form render, how form submission is detected, and added a
formTitle attribute. Like most of the other things in quixote that seemed
strange at first, it seems like the best approach now that I've spent some
time working with it and sort of understand how it works.
If you haven't looked that seriously at it already, I really recommend it.
When converting from my own custom implementation to using the form.py
module as a foundation, I found that my line count went down or stayed about
the same (depending on the particular form) while the code became much more
robust.
Jason
-----Original Message-----
From: quixote-users-bounces@mems-exchange.org
[mailto:quixote-users-bounces@mems-exchange.org]On Behalf Of VanL
Sent: Saturday, May 31, 2003 3:34 PM
To: quixote-users@mems-exchange.org
Subject: [Quixote-users] Best way to handle forms with quixote?
Hello,
I have an app that I am developing that I need feedback on. This may
seem strange, but I'm not sure about the best way to handle a form that
might have bad input.
An example might make the problem clearer. Given the following
flowchart and quixote's URL-space matches code-space concept, where is
the best place to validate the form and respond appropriately?
Form (foo) submission
|
Error? - y -> Go back to foo with appropriate error message
|
-- n -> Go to form (bar)
Option 1:
class foo handles layout and validation for form foo. Form foo POSTS to
/foo, which then either returns (on error) or redirects to /bar (on
successful validation)
This is nice because the layout and validation logic for each form are
all encompassed in a single class (foo). The downside is the use of the
redirect -- seems sloppy and Opera complains about possible security
problems.
Option 2:
Class foo handles layout for form foo. Form foo POSTS to /bar.
Validation is taken care of in class bar, which then redirects to /foo
(on error) or lays out its own form (bar) on success.
This is nice because redirects only occur on errors. However, the
layout and validation are split between classes, which seems sort of messy.
Option 3:
There is only one URL. The app keeps track of the location internally.
All forms post to /genericURL, and the app keeps track of which class
lays out an validates each form.
This is nice because there are no redirects, and a single point of entry
to the web app. However, this completely nullifies quixote's URL-space
matches code-space concept, and may be more insecure.
Any options I missed? What is the best way to handle this situation?
I'm happy to elaborate if the above explanation wasn't clear enough. I
am looking for as much advice and perspective about this issue as I can get.
Thanks,
VanL
_______________________________________________
Quixote-users mailing list
Quixote-users@mems-exchange.org
http://mail.mems-exchange.org/mailman/listinfo/quixote-users