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. <div class="notice">...) 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 -~----------~----~----~----~------~----~------~--~---
