I am currently defining regular expressions in order to capture parameters in a URL, as described in the tutorial. How do I access parameters from the URL as part the HttpRequest object?
My HttpRequest.GET currently returns an empty QueryDict object.
I'd like to learn how to do this without a library, so I can get to know Django better.
When a URL is like domain/search/?q=haha, you would use request.GET.get('q', '').
q is the parameter you want, and '' is the default value if q isn't found.
However, if you are instead just configuring your URLconf**, then your captures from the regex are passed to the function as arguments (or named arguments).
Such as:
(r'^user/(?P<username>\w{0,50})/$', views.profile_page,),
Then in your views.py you would have
def profile_page(request, username):
# Rest of the method
To clarify camflan's explanation, let's suppose you have
the rule url(regex=r'^user/(?P<username>\w{1,50})/$', view='views.profile_page')
an incoming request for http://domain/user/thaiyoshi/?message=Hi
The URL dispatcher rule will catch parts of the URL path (here "user/thaiyoshi/") and pass them to the view function along with the request object.
The query string (here message=Hi) is parsed and parameters are stored as a QueryDict in request.GET. No further matching or processing for HTTP GET parameters is done.
This view function would use both parts extracted from the URL path and a query parameter:
def profile_page(request, username=None):
user = User.objects.get(username=username)
message = request.GET.get('message')
As a side note, you'll find the request method (in this case "GET", and for submitted forms usually "POST") in request.method. In some cases, it's useful to check that it matches what you're expecting.
Update: When deciding whether to use the URL path or the query parameters for passing information, the following may help:
use the URL path for uniquely identifying resources, e.g. /blog/post/15/ (not /blog/posts/?id=15)
use query parameters for changing the way the resource is displayed, e.g. /blog/post/15/?show_comments=1 or /blog/posts/2008/?sort_by=date&direction=desc
to make human-friendly URLs, avoid using ID numbers and use e.g. dates, categories, and/or slugs: /blog/post/2008/09/30/django-urls/
Using GET
request.GET["id"]
Using POST
request.POST["id"]
Someone would wonder how to set path in file urls.py, such as
domain/search/?q=CA
so that we could invoke query.
The fact is that it is not necessary to set such a route in file urls.py. You need to set just the route in urls.py:
urlpatterns = [
path('domain/search/', views.CityListView.as_view()),
]
And when you input http://servername:port/domain/search/?q=CA. The query part '?q=CA' will be automatically reserved in the hash table which you can reference though
request.GET.get('q', None).
Here is an example (file views.py)
class CityListView(generics.ListAPIView):
serializer_class = CityNameSerializer
def get_queryset(self):
if self.request.method == 'GET':
queryset = City.objects.all()
state_name = self.request.GET.get('q', None)
if state_name is not None:
queryset = queryset.filter(state__name=state_name)
return queryset
In addition, when you write query string in the URL:
http://servername:port/domain/search/?q=CA
Do not wrap query string in quotes. For example,
http://servername:port/domain/search/?q="CA"
def some_view(request, *args, **kwargs):
if kwargs.get('q', None):
# Do something here ..
For situations where you only have the request object you can use request.parser_context['kwargs']['your_param']
You have two common ways to do that in case your URL looks like that:
https://domain/method/?a=x&b=y
Version 1:
If a specific key is mandatory you can use:
key_a = request.GET['a']
This will return a value of a if the key exists and an exception if not.
Version 2:
If your keys are optional:
request.GET.get('a')
You can try that without any argument and this will not crash.
So you can wrap it with try: except: and return HttpResponseBadRequest() in example.
This is a simple way to make your code less complex, without using special exceptions handling.
I would like to share a tip that may save you some time.
If you plan to use something like this in your urls.py file:
url(r'^(?P<username>\w+)/$', views.profile_page,),
Which basically means www.example.com/<username>. Be sure to place it at the end of your URL entries, because otherwise, it is prone to cause conflicts with the URL entries that follow below, i.e. accessing one of them will give you the nice error: User matching query does not exist.
I've just experienced it myself; hope it helps!
These queries are currently done in two ways. If you want to access the query parameters (GET) you can query the following:
http://myserver:port/resource/?status=1
request.query_params.get('status', None) => 1
If you want to access the parameters passed by POST, you need to access this way:
request.data.get('role', None)
Accessing the dictionary (QueryDict) with 'get()', you can set a default value. In the cases above, if 'status' or 'role' are not informed, the values are None.
If you don't know the name of params and want to work with them all, you can use request.GET.keys() or dict(request.GET) functions
This is not exactly what you asked for, but this snippet is helpful for managing query_strings in templates.
If you only have access to the view object, then you can get the parameters defined in the URL path this way:
view.kwargs.get('url_param')
If you only have access to the request object, use the following:
request.resolver_match.kwargs.get('url_param')
Tested on Django 3.
views.py
from rest_framework.response import Response
def update_product(request, pk):
return Response({"pk":pk})
pk means primary_key.
urls.py
from products.views import update_product
from django.urls import path
urlpatterns = [
...,
path('update/products/<int:pk>', update_product)
]
You might as well check request.META dictionary to access many useful things like
PATH_INFO, QUERY_STRING
# for example
request.META['QUERY_STRING']
# or to avoid any exceptions provide a fallback
request.META.get('QUERY_STRING', False)
you said that it returns empty query dict
I think you need to tune your url to accept required or optional args or kwargs
Django got you all the power you need with regrex like:
url(r'^project_config/(?P<product>\w+)/$', views.foo),
more about this at django-optional-url-parameters
This is another alternate solution that can be implemented:
In the URL configuration:
urlpatterns = [path('runreport/<str:queryparams>', views.get)]
In the views:
list2 = queryparams.split("&")
url parameters may be captured by request.query_params
It seems more recommended to use request.query_params. For example,
When a URL is like domain/search/?q=haha, you would use request.query_params.get('q', None)
https://www.django-rest-framework.org/api-guide/requests/
"request.query_params is a more correctly named synonym for request.GET.
For clarity inside your code, we recommend using request.query_params instead of the Django's standard request.GET. Doing so will help keep your codebase more correct and obvious - any HTTP method type may include query parameters, not just GET requests."
Background
Let's say I have a url pattern with parameters that will link me to a view in django:
url(
r'^things/(?P<thing_name>\w+)/features/(?P<feature_name>\w+)$',
views.thingFeature,
name='thing_feature'
),
And lets say I have a thing and a feature:
thing = Thing.objects.get(.....)
feature = thing.feature_set.first()
t_name = thing.name
f_name = feature.name
Now Django gives me the awesome ability to get a url that brings me to a page dedicated to a specific feature of a specific thing. I can do that like so:
from django.core.urlresolvers import reverse
url = reverse('thing_feature', thing_name=t_name, feature_name=f_name)
# url == '/things/thing2/features/left-arm'
Question
Now I've stumbled into a situation that I need to specifically address. I'm not looking for a workaround - I'm looking to solve the following problem:
Given a url's name, how do I get the list of kwarg argument names needed to reverse that url?
I am looking for the function get_kwarg_names_for_url. It behaves like so:
url_kwarg_names = get_kwarg_names_for_url('thing_feature')
# url_kwarg_names == ['thing_name', 'feature_name']
url_kwarg_names is now the list of every keyword I need to supply to Django's reverse function in order to reverse the url named "thing_feature".
Any help is appreciated!
Solution
Based on knbk's answer I was able to come up with the following solution:
def get_kwarg_names_for_url(url_name):
resolver = get_resolver(get_urlconf())
reverse_data = resolver.reverse_dict[url_name]
pattern_list = reverse_data[0]
'''
Need to specify the 1st pattern because url regexes can
potentially have multiple kwarg arrangments - this function does
not take this possibility into account.
'''
first_pattern = pattern_list[0]
'''
`first_pattern` is now of the form `(url_string, kwarg_list)` -
all we are interested in is the 2nd value.
'''
return first_pattern[1]
I'll start with a fair warning: this isn't possible using the public API. On top of that, I'm actively working to rewrite the URL dispatcher for 1.10, so this method will most likely break by that time.
First, you need to get the right RegexURLResolver. If the view is not in a namespace, you can use the reverse_dict to get a list of possibilities, and extract the kwargs:
def get_kwargs(view_name):
resolver = urlresolvers.get_resolver()
patterns = resolver.reverse_dict.getlist(view_name)
kwargs = []
for possibility, pattern, defaults in patterns:
for result, params in possibility:
kwargs.append(params)
return kwargs
Since a view name can have multiple patterns with different kwargs (though you'd want to avoid that for your own sanity), this will return a list of each set of possible kwargs. Usually the different sets would be the required kwargs on one side and required + optional kwargs on the other side.
I haven't tested this, but if it doesn't work you can dig around in resolver.reverse_dict for a bit to find out the exact specifics. It wasn't exactly designed with usability in mind.
You should be able to do this with a resolve()
From the Docs:
A ResolverMatch object can then be interrogated to provide information about the URL pattern that matches a URL:
func, args, kwargs = resolve('/some/path/')
Specific to your example code:
url = reverse('thing_feature')
func, args, kwargs = resolve(url)
# args == ['thing_name', 'feature_name']
I am new in web development in django i don't know when to use slug field and when to use query string parameters in the url.Can anyone suggest me practical differences between them.
Using slugs keep urls simple and clean, thereby easy to remember. Consider the following example:
example.com/post/hello-world/
v/s
example.com/?post=hello-world
Obviously, first one is cleaner.
But query string parameters have their uses too. For example, when you search for an object.
example.com/search/?q=hello-world
or when you need to pass multiple parameters
example.com/search/?q=hello+world&lang=en&something=else
In slug related django urls you have a url associated to a view. But you cannot pass querystring parameters to your views.
Ex -example.com/post/hello-world/ does not pass any parameter to your view function.
But if you want to pass additional parameters to your views, ex,
example.com/search/?q=hello-world
here q=hello-world is a query string parameter passed to your views.
And inside your views function you can get these parameters in request.GET
So your views function goes something like this
def helloworld():
qParams = request.GET.get('q', '')
....
....
Hope this helps.
This is a relatively straightforward question.
Is if possible for a method in views.py to dynamically throw back a URL that it caught in err and let a later handler process it. For example:
urls.py
urlpatterns = patterns('myapp.views',
url(r'^foo/(?P<fiz>\d+)/?$', too_broad_method,name="foo"),
url(r'^foo/bar/?$', just_right_method,name="foo"),
)
views.py
def too_broad_method(request,fiz=None):
if fiz == some_dynamic_value:
# under some runtime conditions fiz can equal bar
# Throw some exception to give the URL back??
else:
return process_it()
Lets say for example, /foo/bar should be caught and processed by too_broad_method if an item has the name bar but otherwise it should be processed by just_right_method.
For extra context, I am trying to catch urls of the form app_label/model_name, which doesn't follow any pattern. I'd like these to be caught first, before anything else, which means using a very broad regex.
(Edited since the entire premise of the question changed)
If you need to catch app_name/model_name URLs, my suggestion is that you generate your URL patterns dynamically. There's no reason you couldn't iterate through INSTALLED_APPS, get all available classes that inherit from models.Model, and create URL patterns in a list accordingly. Then you can feed that into the patterns function at the end.
Trying to inform the URL dispatcher that it was somehow "wrong" is misguided, as I've already explained, and you're solving the wrong problem. Instead, you should focus on configuring the URL patterns how you actually need them.
Cant we send a dictionary variable when using HttpResponseRedirect
render_to_response('edited/display.html',context_instance=RequestContext(request,{'newlist': newlist}))
//How can the dictionary and the request sent back again
//sumthing like this
return HttpResponseRedirect('edited/display.html',context_instance=RequestContext(request,{'newlist': newlist}))
Response redirect as name suggests, redirects the user's browser to new URL, so it doesn't make any sense to pass anything else except the new location in HttpResponseRedirect
If you want to pass some data, so that in the view of new location url you can check for that data, pass it as url arguments e.g.
return HttpResponseRedirect('edited/display.html?msg=I was redirected')
So let me add another answer additional to existing ones:
my_url = reverse("my_app.views.my_path") + "?action_result=124"
return HttpResponseRedirect(my_url)
reverse function is: from django.core.urlresolvers import reverse
From the documentation:
The constructor takes a single argument -- the path to redirect to. This can be a fully qualified URL (e.g. 'http://www.yahoo.com/search/') or an absolute URL with no domain (e.g. '/search/').
What you are really looking for, I think is the redirect function introduced in 1.1
You can instead use, for your case,
redirect(view_name,view_parameter)
For that, it may be necessary to modify your view first, to take the new_list parameter, or pass to it, the slug or the id, it takes.