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

Closed
opened 2007-08-13 22:41:13 +00:00 by warner · 1 comment
warner commented 2007-08-13 22:41:13 +00:00
Owner

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.
tahoe-lafs added the
code
major
defect
0.4.0
labels 2007-08-13 22:41:13 +00:00
tahoe-lafs added this to the 0.5.0 milestone 2007-08-13 22:41:13 +00:00
warner commented 2007-08-14 00:51:30 +00:00
Author
Owner

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.
tahoe-lafs 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.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#101
No description provided.