Getting a new ID according to the content type
Getting a new ID according to the content type.
- django
- models
- model
- id
Getting a new ID according to the content type.
A python implementation of the old MySQL PASSWORD() function. This is insecure. There is a reason MySQL changed this in version 4.1. Use it only if you have to!
This snippet provides a uuid field for models, improving on the work in http://www.djangosnippets.org/snippets/335/
The "testdata" tag allows you to inline test data into your templates, similar in spirit to Python doctests. There are two sections--the test data and the actual template to be rendered. In non-test mode your template renders normally from whatever views call it, and there is very little overhead to skip over the test data section (happens at parse time). Here are the goals: 1. Provide convenient way to test templates without surrounding infrastructure. 2. Make templates be self-documenting in terms of expected data. 3. Allow insertion of test data at arbitrary places in template structure. Hello-world looks like this: {% load handytags %} {% testdata %} { 'greeting': 'Hello', 'planet': 'World', } {% --- %} {# This is where the actual template begins #} {{ greeting }} <b>{{ planet }}</b> {% endtestdata %} To invoke it, set up urls.py with something like this: url(r'^testdata/(?P<template_path>.*)', test_template) def test_template(request, template_path): context = {'testdata_use': True} # put request vars into context to help choose # which test data we want to render for field in request.GET: context[field] = request.GET[field] return render_with_request(template_path, context, request) Then call: http://127.0.0.1:8000/testdata/hello_world.html Features: 1. The testdata tag's rendering will expose missing variables a bit more aggressively than Django normally does. 2. You have the full power of the template language to set the test data (which ultimately gets eval'ed as a Python expression). 3. As mentioned above, the tag is mostly unobtrusive. Limitations/caveats: 1. Right now the only data format I support is pure Python, but the tag could be modified pretty easily to support JSON or YAML. 2. The VerboseContext class is pretty heavy-handed--I really just want a hook into Django to tell it to render a section with more strictness about variables. Suggestions welcome. 3. You can put the testdata tag pretty much anywhere, but the normal rules apply...for example, if you are in a template that has the extend tag, you'll want to put the testdata tag in individual blocks.
Default to a static template. **Example:** urlpatterns = patterns('', ... # this rule SHOULD BE the last one (r'^(?P<template>[a-z-_/]+/?)?$', 'myproj.apps.myapp.views.static_template'), )
Renders a view to an email. You need to set all of the required settings for email support.
Get the referer view of a request. **Example:** def some_view(request): ... referer_view = get_referer_view(request) return HttpResponseRedirect(referer_view, '/accounts/login/')
A template filter which wraps imagemagick's `convert` command. The filter acts upon a source image path, and returns the filtered image path. usage: {{ source_path|convert:"-resize 64x64\!" }} The filter parameter is the processing arguments for an ImageMagick 'convert' command. See e.g. http://www.imagemagick.org/Usage/resize/ Every image created is saved in a cache folder. This code does not handle removing obsolete cached images. If the filtered image path exists already, no image processing is carried out, and the path is returned.
Let's say you have a dataset and you want to render a page with sections/subsections/subsubsections down to some arbitrary depth and with arbitrary keys. For example, you might want to show cars broken out by year/price_range or price_range/year or price_range/manufacturer/model. The outliner template tag allows you to support multiple breakdowns of your data in a DRY sort of way. In order to use it, you supply four things: 1. a template for surrounding each subsection (think turtles all the way down) 2. a queryset (really anything iterable) 3. sectionizer dictionary/objects (see sample code, you must supply key_method) 4. inner html to render the lowest subsections The template provides the following: 1. It recursively uses each of your sectionizers' key methods to divvy up data sets. 2. It surrounds each section with templates of your choosing. 3. It renders the inner template for all the "leaf" elements of your tree. 4. It supplies some handy context vars for things like depth and outline ids. What this is not: 1. this is not for arbitrary tree data--think of the tree as fixed depth 2. this is not as simple as the regroup tag--if you have a concrete organization to your data, you should keep it simple and hand-code your templates
I wanted to store ipv4 and ipv6 ip's in django but I wanted to use the postgresql inet network field type: http://www.postgresql.org/docs/8.3/static/datatype-net-types.html and I wanted to use IPy.py IP objects in python. I followed these very helpful examples along with the django documentation: http://vaig.be/2009/03/numeric-ip-field-for-django.html http://www.djangosnippets.org/snippets/1381/ It took me awhile to figure out how this works (not that I completely understand it now..) and figured I would share it. If anyone finds problems with this or can make it better I will definitely use it.
ACNField - Australian Company Number Form Field ABNField - Australian Business Number Form Field Any feedback / Improvements Appreciated.
Encloses all matches of a pattern between the opentag and closetag string. ` {% with "this is a large test" as a %} {{ a|highlightpattern:"a" }} {% endwith %} ` yields this is <b>a</b> l<b>a</b>rge test
I have a need to conditionally format a negative number, a hedgefund's daily price change, Excel style. i.e. show a negative number as a parenthesized number instead of a negative sign. Here is a filter that will do that and more, solving a more general case. See the doctest for examples.
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 is a more compact version of django's [timeuntil](http://docs.djangoproject.com/en/dev/ref/templates/builtins/#timeuntil) filter that only shows hours & minutes. If used like `{{ dt|timeto }}`, will produce output like "1hr 30min". If you know for sure that the server has the same timezone as the [datetime](http://docs.python.org/library/datetime.html#datetime-objects) value, then you don't need [datetutil.tz](http://labix.org/python-dateutil#head-587bd3efc48f897f55c179abc520a34330ee0a62) for utc time conversion.