web page usability: after POST, redirect to somewhere useful #101

New Issue

warner · 2007-08-13T22:41:13Z

warner commented

2007-08-13 22:41:13 +00:00

The human-oriented web interfaces (specifically the POST t=mkdir and t=upload forms) should leave the user's browser on a useful page. This desired behavior is different from what a programmatic client (using PUT or DELETE) ought to get.

Something regressed recently. On 0.4.0-145 (as running on our testnet), when you use the "Create a new directory" button, you are brought back to the original page (and get to notice the new directory line appear in the list). When you use the "Upload a file" button, you are also brought back to the original page (and get to notice the new file line in the list).

In 0.4.0-229 (current trunk), both operations dump you on a page that contains the URI of the newly created object, which is all-but-useless for a human.

I think this needs to be fixed back to its earlier behavior. The "Create new directory" button should perhaps drop you on the newly-created directory.. I'm not sure which behavior would be more useful.

The human-oriented web interfaces (specifically the POST t=mkdir and t=upload forms) should leave the user's browser on a useful page. This desired behavior is different from what a programmatic client (using PUT or DELETE) ought to get. Something regressed recently. On 0.4.0-145 (as running on our testnet), when you use the "Create a new directory" button, you are brought back to the original page (and get to notice the new directory line appear in the list). When you use the "Upload a file" button, you are also brought back to the original page (and get to notice the new file line in the list). In 0.4.0-229 (current trunk), both operations dump you on a page that contains the URI of the newly created object, which is all-but-useless for a human. I think this needs to be fixed back to its earlier behavior. The "Create new directory" button should perhaps drop you on the newly-created directory.. I'm not sure which behavior would be more useful.

warner added the

labels 2007-08-13 22:41:13 +00:00

warner added this to the 0.5.0 milestone 2007-08-13 22:41:13 +00:00

warner self-assigned this 2007-08-13 22:41:13 +00:00

warner commented

2007-08-14 00:51:30 +00:00

Fixed, in changeset:31bfb3950a12a65a: this broke when I fixed the memory footprint problems in
changeset:3bc708529f6a64cb because the when_done= argument that was meant to get us to the right
place shows up in a POST field rather than as a query argument (this is just
how we happened to construct those forms.. with some hackery we could have
stuffed them in the action= URL instead). changeset:3bc708529f6a64cb means that fields no longer
show up in request.args, so we weren't noticing the when_done value and thus
were not doing the intended redirect.

Fixed, in changeset:31bfb3950a12a65a: this broke when I fixed the memory footprint problems in changeset:3bc708529f6a64cb because the when_done= argument that was meant to get us to the right place shows up in a POST field rather than as a query argument (this is just how we happened to construct those forms.. with some hackery we could have stuffed them in the action= URL instead). changeset:3bc708529f6a64cb means that fields no longer show up in request.args, so we weren't noticing the when_done value and thus were not doing the intended redirect.

warner added the

fixed

label 2007-08-14 00:51:30 +00:00

warner closed this issue

2007-08-14 00:51:30 +00:00

Sign in to join this conversation.