No more entries in urls.py...
This is the simple version of a central controller for an app that routes requests by names, thus keeping you from adding a line into urls.py for every, single, page.
Assuming your app name is "account", add the following to your urls.py file:
(r'^account/(?P<path>.*)\.dj(?P<urlparams>/.*)?$', 'account.views.route_request' )
The URL /account/mypage.dj will be routed directly to account.views.py -> process_request__mypage(request, parameters).
You can read more about this on [my blog](http://warp.byu.edu/site/content/1100).
This class decorator will help you when you want to keep a unique boolean (think a 'default' field which should only be only one set to true in a group).
The interesting thing with this, is that it's possible to assign a subset of fields to be used, so that the uniqueness of the field will be guaranteed among only the subset (look at the Example section in the code to understand this behaviour).
This is a better and improved way of doing http://djangosnippets.org/snippets/2676/
Gets the list element at the given index
**Example**
{% for item1 in list1 %}
<p>List1 element: {{ item1 }}</p>
<p>List2 element: {{ list2|get_at_index:forloop.counter0 }}
{% endfor %}
This code will put an entire folder into your media bundle - instead of having to write out every file in a given folder:
*It assumes your static root is a absolute directory*
**Usage**
MEDIA_BUNDLES = (
('init.js',
'coffeescript/init.coffee',
),
bundle_builder('libraries.js', 'javascript/vendor'),
bundle_builder('main.js', 'coffeescript', exclude=['init.js',]),
bundle_builder('templates.js', 'eco'),
)
**Notes**
You may wish to use [cache_utils](http://pypi.python.org/pypi/django-cache-utils) or similar to avoid crawling the filesystem every time the site loads
When uploading a file or image, you need to put it somewhere that's not going to be orphaned by a change in the model. You could use a globally unique value like a uuid, but the django id autofield is a much shorter surrogate field that can be used in a friendly path to the object. The problem with id autofields is that they don't exist when the object is created for the first time - so all files using the id get uploaded to a location 'None' on first save, increasing the likelihood of name collisions.
This postgresql only snippet fetches the next id in a way that is safe for concurrent access.
This snippet only works on postgresql because neither sqlite or mysql have a nextval equivalent. Instead you would have to lock the table for writes and select the last value inserted incrementing it yourself.
This snippet provides getting templates from the model in database.
We work with templates as usual (using as a template name value of the field **"slug"**).
You can do your own application without "TemplateTypes" model - it's added for ability to filter templates. You can use choices or remove "template_type" field and "TemplateTypes" model at all.
For ease of editing, you can connect all this to the admin interface, adding to the field "template_body" widget with syntax highlighting (I used [CodeMirror](http://codemirror.net/)).
The problem with supplying a Django model field with choices parameter is the way you check a value of that field in an object. You do nasty things like this:
if model_instance.choice_field == 1:
The problem of getting rid of hard-coded numbers is recognized over the internet, but I haven't found any short and understandable solution. Basically, we need a enumeration in python, that is ok to use as the Django `choices` model field argument.
I've seen a couple of solutions of DjangoSnippets. Mine is shorter and easier because it only works for integer field choices.
As of django 1.4, the newly introduced `bulk_create()` function has a strong limitation when using SQLite. Namely it causes an error if you want to create more than `999/F` objects, where `F` is the number of fields in the object type.
The above `safe_bulk_create(objs)` function solves this issue by splitting the list of objects to appropriately sized bulks.
This solution also works fine with other db backends, and according to my experiments, it causes no significant overhead comparing to using `bulk_create()` directly.
For more details on the issue, see
https://code.djangoproject.com/ticket/17788
Thanks to charettes for pointing out how to calculate the number of fields in an object.
This is the description of a custom template tag to create DRY menu. It solves the problem of markup duplication in templates of your site. The menu always has one active option and one or several inactive options.
HOW TO USE
Define a structure of your menu in a parent template:
{% defmenu "menu1" %}
{% active %}<span class='active'>__text__</span>{% endactive %}
{% inactive %}<a href='__url__'>__text__</a>{% endinactive %}
{% opt "opt1" "/opt1/" %}Go to opt1{% endopt %}
{% opt "opt2" "/opt2/" %}Go to opt2{% endopt %}
{% opt "opt3" "/opt3/" %}Go to opt3{% endopt %}
{% enddefmenu %}
The menu has it's name (first parameter of the tag 'defmenu'.
First parameter of a tag 'opt' is menu option's name. '__text__' inside of 'active'/'inactive' will be substituted by inner text of a tag 'opt' (Go to opt...), '__url__' indide of 'active'/'inactive' will be substituted by second parameter of a tag 'opt'
To generate menu with one selected option in child template do:
{% menu "menu1" "opt1" %}
Here: "menu1" is a name of menu that was defined by 'defmenu' tag, "opt1" is selected option.
Result of the applying 'menu' is the next:
<span class='active'> Go to opt1</span> <a href='"/opt2/"'>Go to opt2</a> <a href='"/opt3/"'>Go to opt3</a>
This is useful if you have a string that is html encoded (i.e. "<p>Hello world!</p>") and you want to do something more complex than just display it as html, such as using the striptags filter.
You're looking at the most-bookmarked snippets on the site; if you'd like to help useful snippets show up here, sign up for an account and you'll get your own bookmarks list.