Contact form/email with ajax response
This snippets is a simple contact form for use meteora widgets with django For download the meteora.js and all tools http://meteora.astrata.com.mx
- ajax
- javascript
- contact
- meteora
Snippet List
Ajax form with jQuery
I recently got a form working via jQuery and Django. This was not easy for me to do and I thought I'd record my finding here. The form submits via jQuery and the "form" plugin. Please visit jQuery's home page to find all those links. This code handles: * urls.py -- passing both normal and 'Ajax' urls to a view. * views.py -- Handling both kinds of requests so that both normal and ajax submits will work. * The HTML template with the script for submitting and some bling. Error handling === I like to stay DRY so the idea of checking the form for errors in javascript *and* checking it in Django irks me. I decided to leave that up to Django, so the form submits and gets validated on the server. The error messages are sent back to the browser and then displayed.
- ajax
- urls
- fields
- views
- jquery
- form
- errors
Unittest: Compare max_size with column size of database
Changing the size of max_length in the model is fast. But sometimes you forget to update all running systems which use this model. This unittest helps you to find the difference between Model and DB before the users get uncaught exceptions.
- unittest
Translation statistics gatherer
A script that gathers statistics of translated, untranslated and fuzzy literals of translations (be it Django itself or a project using Django). For that it re-scans the tree and generates a up-to-date POT in a temporary location, so the statistics of translation "coverage" are calculated relative to the current status of the tree. It doesn't touch the tree it is analyzing at all. It should be run from the directory containing the `locale/` directory of your project or from the `django/` directory of a Django copy. It is based on the `makemessages` Django management command (or rather its previous standalone `make-messages.py` script incarnation) and uses the same command line switches: * `-d <domain>` -- `<domain>` is `django` or `djangojs`. Optional, defaults to `django`. * `-l <language>` OR * `-a` -- process all languages
- internationalization
- i18n
- l10n
- translations
- status
- statistics
- localization
is_staff decorator
Decorator for views that checks that the user is staff, redirecting to the log-in page if necessary. A wrapper for user_passes_test decorator based on login_required Possible usage: @is_staff def view.... urlpatterns = patterns('', (r'^databrowse/(.*)', is_staff(databrowse.site.root)), )
- decorator
- auth
Localized digits (re)
Another one like [980](http://www.djangosnippets.org/snippets/980/), but using re's instead. I haven't benchmarked these, but my guess is that [981](http://www.djangosnippets.org/snippets/981/) is faster for strings of pure digits and this is faster for larger chunks of text that happen to contain digits. If you're generating the numbers yourself, I'd just use 981 on a number right when you generate it.
- i18n
Localized digits
This is based on [980](http://www.djangosnippets.org/snippets/980/), removing the unnecessary use of StringIO. Hopefully the translation can be educational.
- i18n
Localized digits
Arabic and Farsi languages use their own digits. This template filter translates any digits in the supplied unicode string into the correct ones for the language. The previous version used StringIO to parse the string one character at a time. It now uses regular expressions. I just saw that kcarnold created two snippets that also removed the need for StringIO: [981](http://www.djangosnippets.org/snippets/981/) and [982](http://www.djangosnippets.org/snippets/982/). That last snippet is almost the same as this one.
- i18n
ImageFSStorage
A custom FileSystemStorage made for normalizing extensions. It lets PIL look at the file to determine the format and append an always lower-case extension based on the results.
- storage
- images
MODPYTHON Sample Site Logging
This sample site_logging.py module uses the [MODPYTHON Logging snippet](http://www.djangosnippets.org/snippets/627/). It assigns the ApacheLogHandler class to the main logging object, when Django is run inside MODPYTHON. You must have the MODPYTHON Logging snippet, and name it modpython_logging.py for this to work. Apache will write to virtual host-specific logs only with Python 2.5. Users are encouraged to change the two logging settings. Log Level: handler.setLevel(logging.WARNING) Log Format: logging.Formatter(...)
- logging
- mdpython
HTML to text filter
This filter converts HTML to nicely-formatted text using the text-browser W3M. I use this for constructing e-mail bodies, since it means I don't have to have two templates, one HTML and one plain-text, for each detailed e-mail I want to send. Besides the obvious maintenance benefits, this is nice because Django's templating system isn't well-suited to plain-text where whitespace and line-breaks are significant. I chose W3M because it renders tables nicely and can take in HTML from STDIN (which Lynx can't do). An alternative is ELinks; to use it, change "cmd" to the following: `elinks -force-html -stdin -dump -no-home`
- filter
Refactor template files to use {% block %} tags.
Refactors two similar django template files to use `{% block %}` tags. Takes two template files, where one is a modified version of the other, and looks for differences and similiarities between the two. It then generates refactored (and renamed) versions of each file and a third 'base' file, adding an `{% extends %}` tag as appropriate. Block tags are named with matching numbers in all 3 files, making it easy to do a search and replace with more meaningful labels. `sample_data_in_base` controls whether or not the content from file 1 is copied into place in the base file as an example. Problems: it doesn't identify open `{% for %}` or `{% if %}` tags, so this needs some manual fixing (moving the `{% endfor %}` and `{% endif %}` tags into the proper blocks). It doesn't add the correct path for the `{% extends %}` tag either (ie. `"app/base.html"`). `collapse_whitespace` is not working at all.
- template
- refactor
Custom Django manager that excludes subclasses
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/)
- managers
- models
- model
- subclass
- manager
- inheritance
- subclasses
CustomImageField for Django 1.0 alpha
The venerable CustomImageField, invented by [Scott Barnham](http://scottbarnham.com/blog/2007/07/31/uploading-images-to-a-dynamic-path-with-django/) and rejiggered for newforms-admin by [jamstooks](http://pandemoniumillusion.wordpress.com/2008/08/06/django-imagefield-and-filefield-dynamic-upload-path-in-newforms-admin/#comments). This here is a stab at a [post-Signals-refactor](http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Signalrefactoring) version. Seems to do 'er. Note: This should be pointless once [fs-refactor](http://code.djangoproject.com/ticket/5361) lands.
- models
- fields
- imagefield
- newforms-admin
- signals
djangopath: conveniently set sys.path and DJANGO_SETTINGS_MODULE
In the past, whenever I had a script that I wanted to properly configure the settings for, I would use something like the following idiom at the top of the script: import sys, os; dirname = os.path.dirname # sys.path.insert(0, dirname(dirname(__file__))) sys.path.insert(0, dirname(__file__)) os.environ['DJANGO_SETTINGS_MODULE'] = 'myapp.settings' Notice that this is a relative setting to `__file__` variable in the script. The djangopath function is an attempt to do away with the above such that I can now write the following: from lib import djangopath; djangopath(up=2, settings='myapp.settings') This seems to work for me, but it assumes that you are packaging your script inside your projects/apps. If they are elsewhere then you may need to resort to another method (e.g. absolute paths, etc.) AK
- settings
- path