logging to shell on dev server
You can customize the format. Also you can display variable values that support __str__ or another object-to-string method.
- debug
- debugging
- logging
You can customize the format. Also you can display variable values that support __str__ or another object-to-string method.
Difference from standard Django 1.4 implementation is just structure of list. In django `<input>` elements are *wrapped* by their labels, and look like this:: <ul> <li><label><input/> Label 1</label> <li><label><input/> Label 2</label> </ul> This widget puts labels *after* input elements:: <ul class="form-button-radio"> <li><input/> <label>Label 1</label> <li><input/> <label>Label 2</label> </ul> It makes possible to define style for both inputs and labels, hiding inputs and making labels look like pressable buttons. No javascript needed, just CSS (see docstring). To auto-submit the form when pressing a button, JQuery can be added:: <script> $(document).ready(function() { $('ul.form-button-radio input[type="radio"]').change(function() { $(this).parents('form').submit(); }); }); </script>
I created this template filter to be able to use get_absolute_url in an email template. Save the code into /templatetags/navigation.py Use like this: {% load navigation %} {{ instance.get_absolute_url|siteabsoluteurl:request }}
Displays nested lists / dicts / tuples in an aligned hierarchy to make debugging easy. Accepts all variable types, including nested lists with any mixture of tuples / dictionaries / lists / numbers / strings. Analogous to the PHP print_r($var) function.
The snipped will do : 1.accept image upload by a form 2.check the old image, if there delete it in media folder 3.after delete, save the image uploaded with slug name provided
A decorator that restricts the tags and filters available to template loading and parsing within a function. This is mainly meant to be used when granting users the power of the DTL. You obviously don't want users to be able to do things that could be potentially malicious. The {% ssi %} tag, for example, could be used to display sensitive data if improperly configured. {% load %} gives them access to all the unlimited python code you wrote in your templatetags. {% load sudo %}{% sudo rm -rf / %} o_0 Note that the "load" tag (among others) is not listed in the default tag whitelist. If you parse a template (however indirectly) in a function decorated with this, unlisted builtin tags will behave like undefined tags (ie, they will result in a TemplateSyntaxError). Since {% load %} is not whitelisted, you may want to include some custom tags or filters as "builtins" for convenience. Simply put the module paths to the libraries to include in the `extra` kwarg or the `extra_libraries` list. Generally, this is not recommended, as these libraries need to be carefully and defensively programmed. **NOTE**: This **does not** do anything about cleaning your rendering context! That's completely up to you! This merely restricts what tags and filters are allowed in the templates. Examples: from django.template.loader import get_template safe_get_template = use_safe_templates(get_template) tmpl = safe_get_template('myapp/some_template.html') from django.template import Template use_safe_templates(Template)('{% load sudo %}') # TemplateSyntaxError: Invalid block tag 'load'
Script per Aggiornare i ContentTypes e i Permessi del Model di una Tabella nell Admin [Django Blog](http://www.darioagliottone.it/blog)
When debugging tests you frequently need to inspect response content, making a pdb. set_trace() breakpoint and printing response.content but html isn't enough human readable (even for programmers :D) so, why not open it in your browser? Suposse you save this code in utils.py and you break your testcase as this: response = self.client.get(self.url) import pdb; pdb.set_trace() Then: (pdb) from utils import load_response_on_firefox (pdb) load_response_on_firefox(response) Ta-Da!
A Select widget that allows choices to be disabled. Specify `disabled_choices` to indicate which choices should be present in the list, but disabled. A possible use case for this is a form that displays data that can be edited by privileged user's but only viewed by others.
Example: admin.site.register(YourCoolModel, CustomModelAdmin)
This BasePasswordHasher allows the easy migration of passwords from Drupal to Django 1.4. Drupal stores its passwords using a SHA512 hash, but with some iterations and postprocessing. This snippet allows you to migrate the username and passwords over seamlessly- the only necessary change is truncating the first character of each password hash (since Django 1.4 stores each password as algorithm$hash). Note that this snippet *requires* Django 1.4, but there is no option for that snippet in the list. Provided as a github gist [here](https://gist.github.com/2344345).
This template tag allows you to increment a variable within a template. This avoids the need of having to use the `add` filter and the syntax is quite intuitive.
Converts an integer or floating-point number or a string to a string containing the delimiter character (default comma) after every delimeter_count digits (by default 3 digits)
A Django 1.4 wizard mixin for use cases with a wizard step on the frontpage of your site -- with a request path of `'/'`. Just define the name of the step (e.g. `root_step = 'landing_page'`) and it does the setup and redirection automatically.
This field provides a multi select choice field.