> On Mon, Jun 30, 2003 at 02:44:22PM -0400, Mark Bucciarelli wrote:
> > however, it's not clear to me how using form tokens would help.
> >
> > from a user experience, if they click save, back, then save again, the
> > second save click should have the same behavior as the first.  at
> > least that would be this user's expectation.
>
> I guess it's a matter of opinion.  IMHO, the user cannot expect to use
> the back button to go back and re-submit a form that modified the DB.
> Maybe that opinion is a result of working on systems were the forms are
> data driven.

On the one hand, I have to agree with you (that's why I hadn't noticed the
potential bug that Mark pointed out).  If your users are tech-savvy you can
expect them to understand basic things like that, and they'll work around
it.  I've operated that way more times than I can imagine.  But if your
audience is the proverbial cookie-cooking-grandmother...  Can we honestly
expect her to understand that concept, intuitively? There are a lot of web
users out there who don't even know what a database is.

I think that's a decision that must be made after considering the
application audience.


> In any case, I don't like the underscore in the path.  We generally use:
>
>     /something/new
>     /something//
>     /something//edit
>
> etc.

Yeah.  What you illustrate above is how I started out, before I got the idea
to map "_" to a blank object...  Actually, I think I used 'add' rather than
new, but whatever...  That was my second toy application in Quixote, and
I've learned a bit more of it's capabilities since then.  One of the reasons
I chose to do it that way (the "_" thingie) was to reduce the amount of code
to maintain;  I didn't want a static function that almost (but not exactly)
duplicated the functionality of an object method.

Now, looking at your URL examples above, I can see a way to have my cake and
eat it too...  I could either handle "new" as a component for _q_lookup
(treat it as a reserved id) which creates a blank object and returns the
invocation of it's edit method, or perhaps more cleanly, provide an actual
'new' function in the appropriate namespace that accomplishes the same
thing.  I don't know why that didn't click before...  Of course, you could
also do

    /something/new/edit

... but that just changes the "_" to a "new".

How do you guys handle the implementation of that url space?  Is it a
separate function, or do you map it to an object, or what?

 ...

Reflecting on my earlier idea of using a new guid in the url each time a
page is rendered  (.../appointments/xxxxx-xxxxx-xxxxx-xxxxx/edit) - Total
crap.  Besides being ugly, it has a usability bug in it.  You could never
reuse a url for adding, which means only the app could generate an add url.
You couldn't link to it from a static page, or another app, or whatever.


Jason