This is a simple URI Querystring generator that can be used with Django for generating URI Querystring and preserving the current Currently working to port into a template tag to allow {% urlgen page|5 %} {% urlgen page 5 %} {% urlgen page,5 %} OR {% urlgen sort name display all %} etc..
Adds http://hostname or https://hostname before every URL generated by a Django url function. **Example:** Normally, something like YourModel().get_absolute_url() would return `/2009/09/02/slug`. However, this is not an absolute URL, because it does not include an HTTP schema or host. With this middleware, YourModel().get_absolute_url() will return `http://yourdomain.com/2009/09/02/slug`. This will also work for calls to reverse() or the {% url %} template tag. **Installation:** Drop this code into yourproject/middleware/scriptprefix.py. **Usage:** In your settings.py, add: MIDDLEWARE_CLASSES = ( # ... 'yourproject.middleware.scriptprefix.ScriptPrefixMiddleware', # ... )
A simple context_processor to include location info. Useful for permalinks, site name references, and navigation bars. For example: {% if location.path|match:"/$" %} class="current"{% endif %} See also my [match filter](/snippets/1686/).
A slight modification (and, I think, improvement) of the URL decorator found in [snippet 395](http://www.djangosnippets.org/snippets/395/). What's different between this snippet and 395? 1. We use `django.conf.urls.defaults.url()` when adding patterns 2. We support arbitrary arguments to the `url()` method (like `name="foo"`) 3. We _do not_ support multiple url patterns (this didn't seem useful to me, but if it is I can add it back.)
This snippet helps preserving query parameters such as page number when the view perform redirects. It does not support hooking templates and contexts currently.
This method creates urlpatterns based on view functions that have 'request' as their first parameter. See docstring for details.
This might be a bit cludgy. But the idea is to extend model definition with mixins that can help with defining standard views. So defining a new model as inheriting from Model and All, would allow automatic definition of /get /post type accessors.
I'm using Django's FlatPages, but I want to be able to restrict admin access to Users based on a FlatPage url. For example, User John Doe should be able to edit any FlatPage objects whose URL begins with `/johndoe/` (such as `/johndoe/about/` or `/johndoe/projects/whatever/`). For this to work, John Doe would already need the appropriate admin permissions for FlatPage (such as can_add and can_change). I have set this up as a separate *flatpage_addons* app. It consists of the **Permission** model, which maps a starting URL to one or more django Users. It consists of the minimal necessary admin code so Permissions can be created using the admin. The bulk of this code consists of the *ifhasflatpagepermission* template tag as well as the *flatpage_result_list* inclusion tag. The former works much like django's existing *if*, *else*, *endif* tags while the latter is modified from the django admin's *result_list* inclusion tag. This may not be the most elegant solution to my problem, but so far it works for me. Any comments or suggestions are welcome!
from url_helper import execute, url_ import views urlpatterns += patterns('', url(r'^(?P<urls>.*)', execute, {'views': views}), ) url_(r’/space/:username/:tag/’, views.url_), equal url(r’^space/(?P[^/]+)/(?P[^/]+)/$’,
The {% url %} templatetag is awesome sometimes it is useful to get the full blown URL with the domain name - for instance for links in emails. The **{% absurl %}** templatetag mirrors the behaviour of {% url %} but inserts absolute URLs with the domain of the current Site object. Usage: {% absurl viewname %} >>> http://www.example.org/my/view/
This template tag was built to be used in web applications that are permission based. It renders the html for an html link tag if the user has permissions to access the view (if not, returns an empty string). It also checks if the current token is the active url address and, if so, adds class="active" to the html link for presentation purposes. Example usage: 1. {% url home as home_url %} {% get_link_if_allowed home_url "Home" %} 2. {% url project_dashboard project.id as project_dashboard_url %} {% get_link_if_allowed project_dashboard_url "Projects" %}
This snippet monkey-patches Django's reverse() method (use for generating URLs from vew functions and parameters) to allow certain areas of your site to automatically have URLs with the correct SSL domain in place. This saves you from having to use unnecessary redirects to guide users to an SSL-encrypted version of a page. This should still be used alongside a redirect-based method (such as [this snippet](http://www.djangosnippets.org/snippets/85/)) to ensure that the user can't access an unencrypted version of the page Simply add the code to the files mentioned in the code. This obviously won't work anywhere that doesn't use reverse(), the admin app seems to be an example of this.
Executive summary: url "include" on steroids--granular extra parms and validate names in passing We maintain multiple Django applications, and we use the excellent built-in include mechanism to allow one urls.py to borrow from another: http://docs.djangoproject.com/en/dev/topics/http/urls/ If you scroll down to the section entitled "Passing extra options to include," you will see this annoying limitation: ''' Note that extra options will always be passed to every line in the included URLconf, regardless of whether the line's view actually accepts those options as valid. For this reason, this technique is only useful if you're certain that every view in the included URLconf accepts the extra options you're passing. ''' My snippet overcomes this limitation, allowing you to extend individual urls without polluting the namespace. The function also has the nice side effect of validating that the parent hasn't changed names on you.
This snippet suplies a resolve_to_name function that takes in a path and resolves it to a view name or view function name (given that the path is actually defined in your urlconf). Example: === urlconf ==== urlpatterns = patterns('' (r'/some/url', 'app.views.view'), (r'/some/other/url', 'app.views.other.view', {}, 'this_is_a_named_view'), ) === example usage in interpreter === >>> from some.where import resolve_to_name >>> print resolve_to_name('/some/url') 'app.views.view' >>> print resolve_to_name('/some/other/url') 'this_is_a_named_view'
** DEPRECATED**, use [django-reversetag @ github](http://github.com/ulope/django-reversetag/tree/master) instead. If you want to be able to use context variables as argument for the "url" template tag this is for you. Just put this code somwhere where it will be run early (like your app's _ _init_ _.py) and of you go. Usage: {% url name_of_view_or_variable arg1 arg2 %} **NOTE:** This may possibly break your site! Every view name that is passed to url will be tried to be resolved as a context variable first! So if there is a variable coincidentally named like one of your views THEN IT WILL BREAK. So far it works great for me, but keep an eye out for name clashes.