I'm wondering if it's considered okay (particularly, in Django) to have a URL that's only intended for actions with side effects, that's only intended to be accessed by POST, and that is basically invisible to the user. Let's say, for the sake of making this concrete, I have a little messaging system on my site, and from their inbox, a user should be able to do a bunch of things like:
Delete a message
Mark a message as read
Report a message as spam
With all of those things causing a page refresh, but leading back to the same page. I'm wondering how to design my URLs and views around this. I see (at least) two options, and I have no idea which is more idiomatic.
Option 1)
Have a separate URL and view for each action. So, /inbox/delete-message/ maps to views.delete_message, and so on. At the end of each of those views, it redirects back to /inbox/.
I like the way things are clearly separated with this option. If a user somehow finds themselves sending a GET request to /inbox/delete-message/, that presents a sort of weird situation though (do I throw up an error page? silently redirect them?).
Option 2)
Use the same URL and view for each action, and have a POST parameter that identifies the action. So I would have one rather long inbox view, which would have a bunch of if statements testing whether request.POST['action'] == 'delete', or request.POST['delete'] == 'true' or whatever.
This option feels less clean to me, but I also feel like it's more common.
Which would be preferred by Djangonauts? Or is there another option that's better than either of the above?
A modified option #1 is the best approach. Consider this: suppose we weren't talking about a web app, but instead were just designing an inbox class. Which do you like better, a number of methods (delete_message(), mark_as_spam(), etc), or one big method (do_stuff(action))? Of course you would use the separate methods.
A separate URL for each action, each with a separate view, is far preferable. If you don't like the redirect at the end, then don't use it. Instead, have a render_inbox(request) method that returns an HttpResponse, and call the method at the end of each of your views. Of course, redirecting after a POST is a good way to prevent double-actions, and always leaves the user with a consistent URL.
Even better might be to use Ajax to hide the actions, but that is more involved.
I don't think there's anything wrong with either option, but #2 is potentially better from a performance standpoint. After the action is posted you can render the inbox without a redirect, so it cuts down on the HTTP traffic.
If you're writing a web 2.0 messaging app, you would be using AJAX calls and wouldn't be loading a new page at all. The process would proceed like so:
User clicks [delete] for a message. This button has a javascript action bound to it. This action does the following:
i. Change the UI to indicate that something is happening (grey the message or put up an hourglass).
ii. Send a request to /messages/inbox/1234/delete. (where 1234 is some identifier that indicates which message)
iii. When the response from the server comes back, it should indicate success or failure. Reflect this status in the current UI. For example, on success, refresh the inbox view (or just remove the deleted item).
On the server side, now you can create a URL handler for each desired action (i.e. /delete, /flag, etc.).
If want to use an even more RESTful approach, you would use the HTTP action itself to indicate the action to perform. So instead of including delete in your URL, it would be in the action. So instead of GET or POST, use DELETE /messages/inbox/1234. To set a flag for having been read, use SET /messages/inbox/1234?read=true.
I don't know how straightforward it is in Django to implement this latter recommendation, but in general, it's a good idea utilize the protocol (in this case HTTP), rather than work around it by encoding your actions into a URL or parameter.
I agree that #2 is a better approach.
But take care with overloading the submit <input /> with different methods -- if a user is using it with keyboard input and hits enter, it won't necessarily submit the <input /> you're expecting. Either disable auto-submit-on-enter, or code things up so that if there is more than one thing that submit can do, there's another field that sets what the action should be (eg a 'delete' checkbox, which is tested during a request.POST)
If you went with #1 I'd say that a GET to a POST-only view should be met with a 405 (method not supported) - or, failing that, a 404.
Related
I have a form that needs to process some data in my django app, before the form data is passed to another app.
Is this possible? If not, how might I handle this situation?
Here's a more detailed example of what I need to do. Any suggestions on HOW to accomplish this are welcome!
I have a comments app that tracks comments and replies on arbitrary objects, provides notifications, nested commenting, etc. I'm trying to keep this app generic.
I have another app called "submissions" that uses the comments app. A student enters a submission (via a CommentForm from the comments app) and the results are sent to the comments app which handles it.
In this case, I have two submit buttons on the form: Approve & Return
Regardless of which button is hit the comment app will handle the data the same. However, my submissions app needs to do stuff based on which button was pressed.
The first way I thought of doing this was to pass the form to a submissions app view first, then redirect to the comments app, but I don't think the form data will come with it.
The second way was to only pass it to a submissions app view, then call a function in the comments app, e.g. Comments.objects.create_comment(...) instead of a view to handle the data, but I'm not sure how to pass the form data.
This remembers me very much of this question: django - how to implement a 2-step publish mechanism
You can use the session to save your data after you're done in step one (the submissions app, if I get you correctly), and then redirect the user to step two where they have to submit again (or just redirect again - that'd be a chain, so a bit of a minus there, but works).
Another possible way would be to hack/read a bit into the guts of the comments app to use its interna in the submissions app, so you combine both functionality into one view/function. But I can't help you with that without knowing the code (and it's your project after all, so it's your task).
I have a question about REST design in general and specifically what the best way to implement a solution is in Django Rest Framework. Here it the situation:
Say I have an app for keeping track of albums that the user likes. In the browser, the user sees a list of albums and each one has a check box next to it. Checking the box means you like the album. At the bottom of the page is a submit button.
I want the submit button to initiate an AJAX request that sends tp my API endpoint a list of the ids (as in, the Djano model ids) of the albums that are liked by the user.
My question is, is this a standard approach for doing this sort of thing (I am new to web stuff and REST in particular). In other words, is there a better way to handle the transmission of these data than to send an array of ids like this? As a corollary, if this is an alright approach, how does one implement this in Django Rest Framework in a way which is consistent with its intended methodology.
I am keeping this question a little vague (not presenting any code for the album serializer, for example) intentionally because I am looking to learn some fundamentals, not to debug a particular piece of code.
Thanks a lot in advance!
Consider the upvote button to the left. When you click it, a request may be sent to stackoverflow.com/question/12345/upvote. It creates an "action resource" on the db, so later you can go to your user profile and check out the list of actions you took.
You can consider doing the same thing for your application. It may be a better user experience to have immediate action taken like SO, or a "batch" request like with gmail's check boxes.
So, what issue im running into is how do i know what element of my page made a post request? I have multiple elements that can make the post request on the page, but how do i get the values from the element that created the request? It seems like this would be fairly trivial,but i have come up with nothing, and when doing quite a few google searches i have come up with nothing again.
Is there any way to do this using Bottle?
I had an idea to an a route for an sql page (with authentication of course) for providing the action for the form and use the template to render the id in the action, but i was thinking there had to be a better way to do this without routing another page.
You could add a hidden input field to each form on the page with a specific value. On the server side, check the value of this field to detect which form the post request came from.
I have a simple Django view that confirms the deletion of an instance. On this page is a simple form containing two buttons, "Cancel" and "Delete."
The Cancel button simply returns the user to the page from which the original delete button was pressed.
The Delete button jumps to a second view that performs the actual action. Thus, my URLs are defined as follows:
url(r'^confirmDeleteItem/(?P<item_key>\w+)$', 'confirm_delete_item'), # Confirms
url(r'^deleteItem/(?P<item_key>\w+)$', 'delete_item'), # Performs the action
On the confirmation page, the form is defined with a POST action that visits the second URL:
<form action="/squash/deleteItem/{{ item.key }}/" method="POST">
...
</form>
The problem I have with this is that the Items are fairly large (they store lots of data) and sensitive, so I'd like to force the user to jump through the confirmation hoop every time.
I would like to either prevent the User from visiting the /deleteItem/ page manually, or just hide the browser's loading of this page to avoid from it becoming stored in the history, accidentally bookmarked, etc.
Is wrapping the action in an AJAX call the best way to solve this problem, or are there more standard/preferred solutions? Thanks!
How about setting a session variable in confirmDeleteItem view (i.e. prepareToDelete = item.key) and checking in deleteItem view whether this session variable exists and whether the value match the item.key? Then you'd just need to remove it after actual delete occurred.
A quick idea which I'm not sure of, but should work in your case.
Check your referer in your deleteItem view. Like in this snippet of code. If user didn't come to the delete view from confirmDelete view, redirect him to the appropriate confirmDelete view.
I'd like to output some information that depends on session data in Django. Let's take a "Login" / "Logged in as | Logout" fragment for example. It depends on my request.session['user'].
Of course I can put a user object in the context every time I render a page and then switch on {% if user %}, but that seems to break DRY idea - I would have to add user to every context in every view.
How can I extract a fragment like that and make it more common?
Use template inheritance to derive all of your templates from a common base that suitably uses the common parts of the context, and make all your contexts with a factory function that ensures the insertion in them of those common parts.
Are you trying to make certain areas of your site only accessible when logged on? Or certain areas of a particular page?
If you want to block off access to a whole URL you can use the #login_required decorator in your functions in your view to block certain access. Also, you can use includes to keep the common parts of your site that require user login in a separate html that gets included, that way you're only writing your if statements once.
You may want to use a context processor that includes logic and place it into a variable you can use in any of your pages without adding it to each call.
See more info at How to pass common dictionary data to every page in django