On Sat, May 31, 2003 at 02:34:02PM -0600, VanL wrote:
> Hello,

Hi.  It's late here, so I hope I don't make a hash of this, but I've
been looking at much the same issues recently, too.

> 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 not certain, but I suspect you're trying to fit into Quixote's form
framework.  I've looked at it and don't like it for a variety of
reasons, some of which sound very similar to your issues.  (The
principal reason is that it doesn't seem to fit well with a dense 2D
array of data items, however, so I may be carrying a wrong first
impression of the form framework here.)

I think that what you're looking for is a separation of form handling
(rendering for display and verifying as input) from the Quixote
dispatch mechanism.  That is, I don't see any reason at all for any of
the redirects you describe.  You get the POST request, you verify the
form, and you *call* the function to produce either the error page or
the next/completed page.  As long as the verifying isn't mixed together
with the page generation this is straightforward.

At that point it's up to you to decide whether it's more sensible to
dispatch by URL or by the contents of part of the POSTed data.  I
haven't decided yet if using different URLs as part of the effective
state of the multi-page app's progress is a good and useful idea or
just the remains of early practice in less app-like CGIs.  I'm leaning
towards the view that, at least for the kind of things I've been
working on, it's fairly unimportant - the app's state is a combination
of the URL (hence the script that will be directly invoked), the POSTed
data, and any persistent session data that's lurking in the background.
I can't really see what advantage there is in making the change in
state visible through the URL in general -  it seems gratuitous, like
displaying the value of some internal variable of no real use to the
user.

--
Vs lbh pna ernq guvf, lbh'er va ivbyngvba bs
gur Qvtvgny Zvyyraavhz Pbclevtug Npg.  -- anon.