Login

Tag "context"

Snippet List

PropertyBasedContext

This approach allows you to avoid code duplication to produce same context data for different views. It could be usefull when you are using templates inheritace.

  • context
  • contextprocessor
Read More

Partial Tag

Lets you include another template and pass in named variables. Use like: {% partial field_template field=form.city %} If no key is specified, it will use "item" instead. You may pass in multiple variables as comma-separated key=value pairs.

  • context
  • partial
  • include
  • ssi
Read More

Use MEDIA_URL in flatpages with SSL

This is a copy of [snippet 654](http://djangosnippets.org/snippets/654/), modified to allow dynamic MEDIA_URL, as you might need that for SSL in combination with [snippet 1754](http://djangosnippets.org/snippets/1754/). This is a template filter to enable the use of the MEDIA_URL setting in content from the flatpages database table. It searches for {{ MEDIA_URL }} and replaces it with the current MEDIA_URL added by a context processor. Note: To set up, drop the above code into a file called media_url.py in your templatetags directory in one of your INSTALLED_APPS, and add the filter to your flatpages template like so: {% load media_url %} {{ flatpage.content|media_url:MEDIA_URL }}

  • filter
  • ssl
  • context
  • flatpages
  • processor
Read More

a simple tag with context

simple_tag is nice, but it would be useful if it had a "as variable" clause at the end. This little bit of code factors out the reusable parts and makes a tag almost as simple as simple_tag. Now you can create tags like the following: {% some_function 1 2 as variable %} {% some_function db person %} To add a new function, just do: register.tag("new_function", make_tag(new_function)) (I think you have to take the quotes off a string.)

  • context
  • simple_tag
  • as
Read More

FormWizard inside view with proper context handling and site templating support, without having to use urls.py

Okay - so I came across a really annoying problem earlier, where I wasn't able to *easily* load a formwizard as a segment into an existing view, and wrap it using my existing site template layouts. This was *REALLY* annoying. Especially since I wanted to keep as much of a 'overall' templating and application logic in the views.py (and just leave the forms.py to handle the form and its own templating for the form pages) I spent about 2 hours trying to make this as conventional as possible, and finally came up with a solution. The result is something which looks as similar to the usual functionality. This also meant that there is seperation between form styling and overall site styling, so your forms can be used between multiple sites, and if your overall site template uses extends, then the context support keeps this nicely in order. This also allows you to initialise the formwizard in a nicer way.. Of course, in each file, you'll need to import the necessary bits (like importing the testform from the view etc)

  • requestcontext
  • views
  • context
  • form
  • urls.py
  • wizard
  • formwizard
  • views.py
Read More

Load static media from secure (SSL) static server (Context Processor)

If you request static files such as images, javascript or css using http rather than https, the browser will complain that your site is not secure. This simple context processor will replace http:// with https:// in your MEDIA_URL if your static files are being included from an https page. In your settings.py just replace 'django.core.context_processors.media' with your new context processor.

  • files
  • ssl
  • context
  • static
  • processor
  • secure
  • content
  • media_url
Read More

Updated - Template context debugger with (I)Pdb

Tag to inspect template context, filter to inspect variable. Originally by denis, [http://www.djangosnippets.org/snippets/1550/](http://www.djangosnippets.org/snippets/1550/). This just extracts variables from the context to locals for quicker access and autocompletion (When using ipdb). Additionally, 'vars' holds context keys for quick reference to whats available in the template.

  • template
  • debug
  • context
  • pdb
  • ipdb
Read More

Private Context Decorator

Django's standard inclusion_tag doesn't include context variables by default. When you add takes_context you are required to manually merge the context variables into the dict which your tag returns, which tends to result in wasteful code or [possibly accidentally] leaking variables into the global context (`context.update({…})`). This decorator allows your inclusion tag to remain simple and still have safe access to the global context for things like `MEDIA_URL`: @register.inclusion_tag('my_template') @private_context def my_tag(context, …): return {"foo": 1, "bar": 2}

  • templatetag
  • decorator
  • context
  • inclusion_tag
Read More

Template context debugger with (I)Pdb

This allows you to set up a breakpoint anywhere in your template code, by simply writing {% pdb_debug %}. You can then access your context variables using context.get(..) at the pdb prompt. Optionally, install the ipdb package for colors, completion, and more (easy_install ipdb).

  • template
  • debug
  • context
  • pdb
  • ipdb
Read More

render_as_template template tag

This is a template tag that works like `{% include %}`, but instead of loading a template from a file, it uses some text from the current context, and renders that as though it were itself a template. This means, amongst other things, that you can use template tags and filters in database fields. For example, instead of: `{{ flatpage.content }}` you could use: `{% render_as_template flatpage.content %}` Then you can use template tags (such as `{% url showprofile user.id %}`) in flat pages, stored in the database. The template is rendered with the current context. Warning - only allow trusted users to edit content that gets rendered with this tag.

  • template
  • tag
  • context
Read More

Variable resolving URL template tag

** 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.

  • template
  • tag
  • url
  • context
  • variable
  • resolve
  • resolving
Read More

A GET string modifier templatetag

This template tag takes the current GET query, and modifies or adds the value you specify. This is great for GET-query-driven views, where you want to provide URLs which reconfigure the view somehow. **Example Usage:** `{% get_string "sort_by" "date" %}` returns `all=your&current=get&variables=plus&sort_by=date`

  • templatetag
  • get
  • context
  • request
Read More

Render specific blocks from templates (useful for AJAX, alternative)

Special thanks to the author of snippet 769 who provided most of the code for this snippet. Major differences: 1.Simpler/better handling of "extends" block tag 2.Searches If/Else blocks 3.Less code 4.Allow list of templates to be passed which is closer to the behavior of render_to_response

  • template
  • block
  • templates
  • render
  • context
  • blocks
Read More

20 snippets posted so far.