Works much like an inclusion_tag but allows the template_name to be given as an argument or defaults to partials/MODELNAME.html where MODELNAME is 'got' from the context object you want to render. Its very rough so improvements very welcome!
It would be nice to be able to pass new context variables as template tag [keyword] arguments for use in the template to be rendered so you basically have a template tag equivalent for render_to_string...
Example usage in a template:
{% render_partial post %} or {% render_partial post partials/super_post.html %}
When you switch you django project from 0.9.6 to 1.0, you can use this script to generate admin.py automatically.
You need copy cvt.py to the parent directory of your project(where your project lies) and type "python cvt.py <project> <app>". The admin.py will generated in the <project>/<app>(where it should be!).
Enjoy this small work!
This TestSettingsManager class takes some of the pain out of making temporary changes to settings for the purposes of a unittest or doctest. It will keep track of the original settings and let you easily revert them back when you're done.
It also handles re-syncing the DB if you modify INSTALLED_APPS, which is especially handy if you have some test-only models in tests/models.py. This makes it easy to dynamically get those models synced to the DB before running your tests.
Sample doctest usage, for testing an app called "app_under_test," that has a tests/ sub-module containing a urls.py for testing URLs, a models.py with some testing models, and a templates/ directory with test templates:
>>> from test_utils import TestManager; mgr = TestManager()
>>> import os
>>> mgr.set(INSTALLED_APPS=('django.contrib.contenttypes',
... 'django.contrib.sessions',
... 'django.contrib.auth',
... 'app_under_test',
... 'app_under_test.tests'),
... ROOT_URLCONF='app_under_test.tests.urls',
... TEMPLATE_DIRS=(os.path.join(os.path.dirname(__file__),
... 'templates'),))
...do your doctests...
>>> mgr.revert()
Here's an example of writing generic views in an object-oriented style, which allows for very fine-grained customization via subclassing. The snippet includes generic create and update views which are backwards compatible with Django's versions.
To use one of these generic views, it should be wrapped in a function that creates a new instance of the view object and calls it:
def create_object(request, *args, **kwargs):
return CreateObjectView()(request, *args, **kwargs)
If an instance of one of these views is placed directly in the URLconf without such a wrapper, it will not be thread-safe.
This replaces the html select box for a foreign key field with a link to that object's own admin page. The foreign key field (obviously) is readonly.
This is shamelessly based upon the [Readonly admin fields](http://www.djangosnippets.org/snippets/937/) snippet. However, that snippet didn't work for me with ForeignKey fields.
from foo.bar import ModelLinkAdminFields
class MyModelAdmin(ModelLinkAdminFields, admin.ModelAdmin):
modellink = ('field1', 'field2',)
See the description in the blog entry at [http://sciyoshi.com/blog/2008/aug/27/using-akismet-djangos-new-comments-framework/](http://sciyoshi.com/blog/2008/aug/27/using-akismet-djangos-new-comments-framework/)
Sometimes it's useful to sign data to ensure the user does not tamper with it - for example, cookies or hidden form variables. SHA1 is cryptographically secure but weighs in at 40 characters, which is pretty long if you're going to be passing the data around in a URL or a cookie.
These functions knock an SHA1 hash down to just 27 characters, thanks to a base65 encoding that only uses URL-safe characters (defined as characters which are unmodified by Python's urllib.urlencode function). This compressed hash can then be passed around in cookies or URLs, and uncompressed again when the signature needs to be checked.
UPDATE: You probably shouldn't use this; see [http://fi.am/entry/urlsafe-base64-encodingdecoding-in-two-lines/](http://fi.am/entry/urlsafe-base64-encodingdecoding-in-two-lines/) for a smarter approach based on Python's built-in base64 module.
a simple guestbook. the guestbook-area and entries can (and should) be styled by CSS. The template extends a "base.html", which should contain a "content" block.
The Model is very simple without moderation, admin-comment or any other advanced features, but its easy to extend.
i.e. add a Field "active=models.BooleanField()" and add "exclude=['active']" to the forms.EntryForm.Meta class for moderated Entries.
Now you can switch the entries on/off in the admin-interface by setting active=True/False
this snippet is public domain, use for everything you want.
UPDATE: added basic SPAM protection (a do_not_fill field), but you might want to try a captcha-form/Field like snippet 812
simple middleware and context processor for session-based messaging with types
Heavily inspired by patches on ticket 4604. Differs in that in this a notification
has type.
Installation:
* add notifications.NotificationMiddleware to MIDDLEWARE_CLASSES
* and notifications.notifications to TEMPLATE_CONTEXT_PROCESSORS
That assumes notifications.py is on pythonpath. If notifications.py lives in
your project dir, prefix those with '(projectname).'
Example use:
* request.notifications.create('Some bland information message.')
* request.notifications.create('Some more exciting error message.', 'error')
Example template code:
`{% if notifications %}
<ul id="notifications">
{% for notification in notifications %}<li class="{{ notification.type }}">{{ notification.content }}</li>
{% endfor %}
</ul>
{% endif %}`
[rendered example](http://traviscline.com/blog/2008/08/23/django-middleware-session-backed-messaging/)
A simple backend which allows you to login with either an email address or a username.
It should be combined with another backend for checking permissions:
AUTHENTICATION_BACKENDS = (
'myproject.accounts.backends.EmailOrUsernameModelBackend',
'django.contrib.auth.backends.ModelBackend'
)
This script is an adaptation from http://www.djangosnippets.org/snippets/678/ . Here, it doesnt use the cache middleware but relies on sessions.
The script set a session cookie to identify the upload and track it to make it available for a progress bar like this one : http://www.djangosnippets.org/snippets/679/ . Note the progress bar cannot work with development server as it is single-threaded. Tested with apache/mod_python and mod_wsgi.
any comments appreciated ;)