0

I am rather new to django, and am looking at where to define a slug in django when creating a backend without models. the url is created as such:

url(r'^main/(?P<slug>[-\w]+)/', include('main.urls')),

I have slugs within my main.urls which I define inside of each view function. Im not exactly sure where to define this slug(link, whatever you may call it). On other django slug examples, the common way is in a model, and I am currently talking to a program rather then creating my own models.

Would this be in the urls.py, or views.py (in the project, not app)? Thank you so much. Hopefully this is understandable.

Desario
  • 13
  • 1
  • 4
  • `slug` should be the parameter to the request functions (like get, post) in your `views` class – Moinuddin Quadri Apr 21 '17 at 20:08
  • got it, so I should put a decorator on each of my views (there are about 12 or so in my main.urls) that would define this parameter. Is there a efficient way? – Desario Apr 21 '17 at 20:17
  • 1
    I'm not sure what you want the slug *for*. A slug is a way to identify a particular record in the db, so it only really makes sense with a model. What, exactly, do you want to do with it? If you are just differentiating between URLs that go to different views, that's just a standard URL pattern and doesn't need a slug. – Daniel Roseman Apr 21 '17 at 20:35

1 Answers1

0

It's not hard. Really.

In url-configs each entry is simply a regular expression which has to match a url that is visited by an end user. r'^main/(?P<slug>[-\w]+)/' will for example match with: http://localhost:8000/main/some-slug/

You can use a special kind of syntax in your regular expression to extract matched data and pass that data as a variable to your view function.

The bit that does that is (?P<slug>[-\w]+) it puts matched words (in this case a slug) into a variable called slug (the <slug> part, it defines the variable name). In this humble example the slug variable will be set to "some-slug".

The variable will be accessible in your view like this:

from django.http import HttpResponse

def handle_my_view(request, slug=homepage):
 # do stuff with slug    
 return HttpResponse("I did stuff with slug: {}".format(slug))

Learn more about, and fiddle with regular expressions

At http://www.regexr.com

But why do i see slugs used in models?:

A slug (or named variable, coming from a url 'interception') can be used for anything. Commonly the slug variable itself will be used to retrieve a database record of some sorts... And that involves using models.

You can do whatever you want with them; add stuff, subtract stuff, capitalize, whatever. The sky is the limit.

From the Django docs:

https://docs.djangoproject.com/en/1.10/topics/http/urls/#named-groups

Named groups

The above example used simple, non-named regular-expression groups (via parenthesis) to capture bits of the URL and pass them as positional arguments to a view. In more advanced usage, it’s possible to use named regular-expression groups to capture URL bits and pass them as keyword arguments to a view.

In Python regular expressions, the syntax for named regular-expression groups is (?Ppattern), where name is the name of the group and pattern is some pattern to match.

Here’s the above example URLconf, rewritten to use named groups:

from django.conf.urls import url

from . import views

urlpatterns = [
    url(r'^articles/2003/$', views.special_case_2003),
    url(r'^articles/(?P<year>[0-9]{4})/$', views.year_archive),
    url(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/$', views.month_archive),
    url(r'^articles/(?P<year>[0-9]{4})/(?P<month>[0-9]{2})/(?P<day>[0-9]{2})/$', views.article_detail),
]

This accomplishes exactly the same thing as the previous example, with one subtle difference: The captured values are passed to view functions as keyword arguments rather than positional arguments. For example:

A request to /articles/2005/03/ would call the function views.month_archive(request, year='2005', month='03'), instead of views.month_archive(request, '2005', '03').

A request to /articles/2003/03/03/ would call the function views.article_detail(request, year='2003', month='03', day='03').

In practice, this means your URLconfs are slightly more explicit and less prone to argument-order bugs – and you can reorder the arguments in your views’ function definitions. Of course, these benefits come at the cost of brevity; some developers find the named-group syntax ugly and too verbose.

niellus
  • 74
  • 2