Re: Post/redirect/get pattern for file upload with confirmation
Accidentally posted the first reply and you already beat me to my actual reply, wow. The "not feeling right" part meant to imply that the disadvantages I could see for both made me wonder if there wasn't another (and better) option available, but based on your answer it seems that won't happen anytime soon. On Nov 16, 1:51 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Hi Malcolm, > thanks for the fast reply. > > What is the downside of sticking this kind of information into a > session, just that the session backend needs to carry this amount of > information around and cookies have to be enabled for it to work? I > otherwise would prefer it over (2) just for the cleaner URL. > > Thanks > Stefan > > On Nov 16, 1:16 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > > On Sun, 2008-11-16 at 12:58 +0100, Stefan Wallner wrote: > > > p,,,[ > > > > My basic idea would be to use the same URL and view/template for > > > getting the directory listing and posting a file for uploading to it. > > > If a file is uploaded successfully the renamed file name and the users > > > that received the email should be listed in a notification part of the > > > template (i.e. ...) which confirms to the user > > > that everything is ok. > > > > Now I am stuck on how to best do this. POST/REDIRECT/GET does not seem > > > to fit here, since HttpResponseRedirect cannot pass any parameters to > > > a template and redirecting to the same URL does not make sense anyway. > > > What other pattern could/should I use? > > > I suspect you're actually asking the wrong question. The question isn't > > "where should I redirect to?", but rather "how can I tell when loading > > the file listing page, after a GET request, that some extra information > > about the renamed file and notified people should be displayed?". It > > doesn't matter what URL you actually retrieve after the file is > > uploaded, that question still remains -- how to tell that you need to > > display that information. > > > Once you've solved that problem, redirecting the the normal file listing > > page is quite a natural place to go, since it shows the file listing > > (plus this extra information sometimes), but that's really a side-issue. > > > You have at least a couple of choices: > > > (1) Use sessions and store the fact that a file was just uploaded (and > > renamed) and the list of people notified in a key in the session. When > > the user accesses the directory listing page using GET and if they have > > that session key, display the extra information and then remove it from > > the session (so it's displayed only once). Or possibly you want to keep > > it in the session for a period of time or something. In any case, you > > can use the session. > > > (2) The more HTTP/REST-like approach is to come up with a unique > > identifier for the page that displays the newly uploaded information. > > This identifier tells you (the webserver side of the code) that you need > > to display the new filename and list of notified people. One way to do > > this is to add a parameter to the GET request that is, say, the primary > > key (or some other token) of the newly uploaded file. Then, when you are > > processing that page, if the querystring contains that parameter, you > > retrieve the new filename and the list of people who would have been > > notified from the database. > > > The second way uses the fact that you can attach a querystring to a URL > > and that's quite valid for an HTTP redirect. It's also probably not that > > hard to implement, providing you can easily determine from the id of the > > file who the recipients were. The slight drawback is that anybody who > > knows that URL can view the same information. Maybe that's not a > > problem. If it is, you can use access checking (e.g. the special display > > information is only presented if the currently logged in user is the > > person who uploaded the file with that id). > > > Thus the 'normal' view is, say, /foo/file_listing/ and the target after > > an upload is, say, /foo/file_listing/?upload=123. > > > The first of these two choices is pretty fast to implement, but puts > > information in the session, which you may or may not like doing. The > > second is more "natural" in a way, but you have to do some work to > > process the incoming optional querystring. It's still not particularly > > hard, though. > > > Regards, > > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Post/redirect/get pattern for file upload with confirmation
Hi Malcolm, thanks for the fast reply. What is the downside of sticking this kind of information into a session, just that the session backend needs to carry this amount of information around and cookies have to be enabled for it to work? I otherwise would prefer it over (2) just for the cleaner URL. Thanks Stefan On Nov 16, 1:16 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sun, 2008-11-16 at 12:58 +0100, Stefan Wallner wrote: > > p,,,[ > > > My basic idea would be to use the same URL and view/template for > > getting the directory listing and posting a file for uploading to it. > > If a file is uploaded successfully the renamed file name and the users > > that received the email should be listed in a notification part of the > > template (i.e. ...) which confirms to the user > > that everything is ok. > > > Now I am stuck on how to best do this. POST/REDIRECT/GET does not seem > > to fit here, since HttpResponseRedirect cannot pass any parameters to > > a template and redirecting to the same URL does not make sense anyway. > > What other pattern could/should I use? > > I suspect you're actually asking the wrong question. The question isn't > "where should I redirect to?", but rather "how can I tell when loading > the file listing page, after a GET request, that some extra information > about the renamed file and notified people should be displayed?". It > doesn't matter what URL you actually retrieve after the file is > uploaded, that question still remains -- how to tell that you need to > display that information. > > Once you've solved that problem, redirecting the the normal file listing > page is quite a natural place to go, since it shows the file listing > (plus this extra information sometimes), but that's really a side-issue. > > You have at least a couple of choices: > > (1) Use sessions and store the fact that a file was just uploaded (and > renamed) and the list of people notified in a key in the session. When > the user accesses the directory listing page using GET and if they have > that session key, display the extra information and then remove it from > the session (so it's displayed only once). Or possibly you want to keep > it in the session for a period of time or something. In any case, you > can use the session. > > (2) The more HTTP/REST-like approach is to come up with a unique > identifier for the page that displays the newly uploaded information. > This identifier tells you (the webserver side of the code) that you need > to display the new filename and list of notified people. One way to do > this is to add a parameter to the GET request that is, say, the primary > key (or some other token) of the newly uploaded file. Then, when you are > processing that page, if the querystring contains that parameter, you > retrieve the new filename and the list of people who would have been > notified from the database. > > The second way uses the fact that you can attach a querystring to a URL > and that's quite valid for an HTTP redirect. It's also probably not that > hard to implement, providing you can easily determine from the id of the > file who the recipients were. The slight drawback is that anybody who > knows that URL can view the same information. Maybe that's not a > problem. If it is, you can use access checking (e.g. the special display > information is only presented if the currently logged in user is the > person who uploaded the file with that id). > > Thus the 'normal' view is, say, /foo/file_listing/ and the target after > an upload is, say, /foo/file_listing/?upload=123. > > The first of these two choices is pretty fast to implement, but puts > information in the session, which you may or may not like doing. The > second is more "natural" in a way, but you have to do some work to > process the incoming optional querystring. It's still not particularly > hard, though. > > Regards, > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Post/redirect/get pattern for file upload with confirmation
On Sun, 2008-11-16 at 04:39 -0800, [EMAIL PROTECTED] wrote: > Hi Malcolm, > thanks for the fast response. I had thought about both approaches, but > both didn't feel 100% right (more a gut feeling than anything). Then you're going to have provide more information about what would "feel right", since both those approaches are technically valid and common to boot. The second one is basically the canonical way to do it for the REST style of architecture. The exact form of the URL is a design issue -- it doesn't have to use a querystring, after all -- but the naming of a resource to do conditional data display is standard. Since you've nixed the two standard ways to do this, aren't you rapidly running out of choices? You don't want to store the information in the session (which is the only really transient way to move data between requests that doesn't go via the URL) and you don't want to create a new identifiable URL for the new resource. It seems like we're reduced to using The Force to convey the information at that point. That's not supported in Python yet. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Post/redirect/get pattern for file upload with confirmation
Hi Malcolm, thanks for the fast response. I had thought about both approaches, but both didn't feel 100% right (more a gut feeling than anything). On Nov 16, 1:16 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sun, 2008-11-16 at 12:58 +0100, Stefan Wallner wrote: > > p,,,[ > > > My basic idea would be to use the same URL and view/template for > > getting the directory listing and posting a file for uploading to it. > > If a file is uploaded successfully the renamed file name and the users > > that received the email should be listed in a notification part of the > > template (i.e. ...) which confirms to the user > > that everything is ok. > > > Now I am stuck on how to best do this. POST/REDIRECT/GET does not seem > > to fit here, since HttpResponseRedirect cannot pass any parameters to > > a template and redirecting to the same URL does not make sense anyway. > > What other pattern could/should I use? > > I suspect you're actually asking the wrong question. The question isn't > "where should I redirect to?", but rather "how can I tell when loading > the file listing page, after a GET request, that some extra information > about the renamed file and notified people should be displayed?". It > doesn't matter what URL you actually retrieve after the file is > uploaded, that question still remains -- how to tell that you need to > display that information. > > Once you've solved that problem, redirecting the the normal file listing > page is quite a natural place to go, since it shows the file listing > (plus this extra information sometimes), but that's really a side-issue. > > You have at least a couple of choices: > > (1) Use sessions and store the fact that a file was just uploaded (and > renamed) and the list of people notified in a key in the session. When > the user accesses the directory listing page using GET and if they have > that session key, display the extra information and then remove it from > the session (so it's displayed only once). Or possibly you want to keep > it in the session for a period of time or something. In any case, you > can use the session. > > (2) The more HTTP/REST-like approach is to come up with a unique > identifier for the page that displays the newly uploaded information. > This identifier tells you (the webserver side of the code) that you need > to display the new filename and list of notified people. One way to do > this is to add a parameter to the GET request that is, say, the primary > key (or some other token) of the newly uploaded file. Then, when you are > processing that page, if the querystring contains that parameter, you > retrieve the new filename and the list of people who would have been > notified from the database. > > The second way uses the fact that you can attach a querystring to a URL > and that's quite valid for an HTTP redirect. It's also probably not that > hard to implement, providing you can easily determine from the id of the > file who the recipients were. The slight drawback is that anybody who > knows that URL can view the same information. Maybe that's not a > problem. If it is, you can use access checking (e.g. the special display > information is only presented if the currently logged in user is the > person who uploaded the file with that id). > > Thus the 'normal' view is, say, /foo/file_listing/ and the target after > an upload is, say, /foo/file_listing/?upload=123. > > The first of these two choices is pretty fast to implement, but puts > information in the session, which you may or may not like doing. The > second is more "natural" in a way, but you have to do some work to > process the incoming optional querystring. It's still not particularly > hard, though. > > Regards, > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Post/redirect/get pattern for file upload with confirmation
On Sun, 2008-11-16 at 12:58 +0100, Stefan Wallner wrote: p,,,[ > My basic idea would be to use the same URL and view/template for > getting the directory listing and posting a file for uploading to it. > If a file is uploaded successfully the renamed file name and the users > that received the email should be listed in a notification part of the > template (i.e. ...) which confirms to the user > that everything is ok. > > Now I am stuck on how to best do this. POST/REDIRECT/GET does not seem > to fit here, since HttpResponseRedirect cannot pass any parameters to > a template and redirecting to the same URL does not make sense anyway. > What other pattern could/should I use? I suspect you're actually asking the wrong question. The question isn't "where should I redirect to?", but rather "how can I tell when loading the file listing page, after a GET request, that some extra information about the renamed file and notified people should be displayed?". It doesn't matter what URL you actually retrieve after the file is uploaded, that question still remains -- how to tell that you need to display that information. Once you've solved that problem, redirecting the the normal file listing page is quite a natural place to go, since it shows the file listing (plus this extra information sometimes), but that's really a side-issue. You have at least a couple of choices: (1) Use sessions and store the fact that a file was just uploaded (and renamed) and the list of people notified in a key in the session. When the user accesses the directory listing page using GET and if they have that session key, display the extra information and then remove it from the session (so it's displayed only once). Or possibly you want to keep it in the session for a period of time or something. In any case, you can use the session. (2) The more HTTP/REST-like approach is to come up with a unique identifier for the page that displays the newly uploaded information. This identifier tells you (the webserver side of the code) that you need to display the new filename and list of notified people. One way to do this is to add a parameter to the GET request that is, say, the primary key (or some other token) of the newly uploaded file. Then, when you are processing that page, if the querystring contains that parameter, you retrieve the new filename and the list of people who would have been notified from the database. The second way uses the fact that you can attach a querystring to a URL and that's quite valid for an HTTP redirect. It's also probably not that hard to implement, providing you can easily determine from the id of the file who the recipients were. The slight drawback is that anybody who knows that URL can view the same information. Maybe that's not a problem. If it is, you can use access checking (e.g. the special display information is only presented if the currently logged in user is the person who uploaded the file with that id). Thus the 'normal' view is, say, /foo/file_listing/ and the target after an upload is, say, /foo/file_listing/?upload=123. The first of these two choices is pretty fast to implement, but puts information in the session, which you may or may not like doing. The second is more "natural" in a way, but you have to do some work to process the incoming optional querystring. It's still not particularly hard, though. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Post/redirect/get pattern for file upload with confirmation
Hi, I am confused on how to best use the post/redirect/get pattern for the following problem: Part of the application I am writing is a basic file manager, i.e. it lists directory contents to users and lets users download files or upload a file to the directory. Upon upload the file is renamed (to include date and user) and then saved to disk, users that need to be informed receive an email that a new file was uploaded. My basic idea would be to use the same URL and view/template for getting the directory listing and posting a file for uploading to it. If a file is uploaded successfully the renamed file name and the users that received the email should be listed in a notification part of the template (i.e. ...) which confirms to the user that everything is ok. Now I am stuck on how to best do this. POST/REDIRECT/GET does not seem to fit here, since HttpResponseRedirect cannot pass any parameters to a template and redirecting to the same URL does not make sense anyway. What other pattern could/should I use? Right now I am just doing a render_to_response with the same template, regardless of whether it is a first GET of the page or the POST for the file upload. Of course this means once a file was uploaded and the notification is displayed any refresh of the will give you a browser warning about resending data which I would like to avoid. Any suggestions? Thanks Stefan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
