EmailListField for Django
A simple Django form field which validates a list of emails. [See this at my blog](http://sciyoshi.com/blog/2009/aug/08/emaillistfield-django/)
- fields
- forms
- form
- field
- email-list
A simple Django form field which validates a list of emails. [See this at my blog](http://sciyoshi.com/blog/2009/aug/08/emaillistfield-django/)
This is a rewrite of [snippet #1006](http://www.djangosnippets.org/snippets/1006/) to use the moderation features available in Django's comments framework. This is more customizable than the signals approach and works well if other moderation features are being used. If you want to make comments that are flagged as spam become hidden instead of deleted, change the allow() method to moderate(). [See the blog post here](http://sciyoshi.com/blog/2009/jul/17/prevent-django-newcomments-spam-akismet-reloaded/)
[See the blog entry](http://sciyoshi.com/blog/2008/nov/18/rails-mvc-controllers-django/) Allows using controllers for views. This allows for nice subclassing to override behavior of views. `Controller.urls` (see below) works fine for subclasses as well. Similar to [snippet #1165](http://www.djangosnippets.org/snippets/1165/) except that it won't break reverse URL resolving and regex validation in URLs. In `views.py`: import mvc class MyController(mvc.Controller): @mvc.view('myview/$', 'myview') def my_view(self): # do something with self.request return HttpResponse('something') class Meta(mvc.Controller.Meta): url_prefix = 'mycontroller-' In `urls.py`: from . import views urlpatterns = patterns('', # ... other urls here ... *views.MyController.urls(r'prefix/') ) Then the view `MyController.my_view` will be accessible from `'prefix/myview/'` and have the name `'mycontroller-myview'`, i.e. `reverse('mycontroller-myview')` will work as expected.
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/)
When you're using Django model inheritance, sometimes you want to be able to get objects of the base class that aren't instances of any of the subclasses. You might expect the obvious way of doing this, `SuperModel.objects.filter(submodel__isnull=True)`, to work, but unfortunately it doesn't. (Neither does `SuperModel.objects.filter(submodel__supermodel_ptr=None)`, or any other convoluted way I could think of doing it.) Here's a nicer approach for doing this. [The blog entry is here.](http://sciyoshi.com/blog/2008/aug/07/custom-django-manager-excludes-subclasses/)
Here's a nice way of easily passing only certain settings variables to the template. Because of the way Django looks up context processors, we need a little hack with sys.modules. The [blog entry is here](http://sciyoshi.com/blog/2008/jul/10/dynamic-django-settings-context-processor/).
See [the blog entry](http://sciyoshi.com/blog/2008/jul/08/django-choicefield-other-choice/) for details.
Allows getting the rendered content of a specific block tag. Useful if you want to send just a part of a template back for an AJAX request. Works for arbitrary template inheritance, even if a block is defined in the child template but not in the parent. Example: In `test1.html`: {% block block1 %}block1 from test1{% endblock %} {% block block2 %}block2 from test1{% endblock %} In `test2.html`: {% extends 'test1.html' %} {% block block1 %}block1 from test1{% endblock %} And from the Python shell: >>> from django.template import loader, Context >>> from template import render_block_to_string >>> print render_block_to_string('test2.html', 'block1', Context({})) u'block1 from test2' >>> print render_block_to_string('test2.html', 'block2', Context({})) u'block2 from test1' UPDATE: See also [zbyte64](http://www.djangosnippets.org/users/zbyte64/)'s implementation in snippet [#942](http://www.djangosnippets.org/snippets/942/)
I wanted lookups on tags to be case insensitive by default, so that things like Tag.objects.get(name='Tag') would return any similar tags (ignoring case differences), i.e. `<Tag: tag>`. This snippet makes lookup on the 'name' field case-insensitive by default, although case-sensitive lookups can still be achieved with 'name__exact'. Methods like get_or_create will work as expected and be case-insensitive.
sciyoshi has posted 9 snippets.