You can download these files from [here](http://huangyilib.googlecode.com/svn/trunk/mashi_django) Django template, mako, genshi, they are the best three templates in python, aren't they? How to use these files ? [Using Mako in Django](http://fuzzythinker.blogspot.com/2007/04/using-mako-in-django.html) -- by John Leung
In development, we need a SMTP Server to see the results of send mail via SMTP protocol in Python application. Instead of configure a mail daemon, we could use this little script to receive the SMTP request, and save each session into an EML file. *.eml could be viewed with your favorite email client, you need not send them out. [EML description](http://filext.com/detaillist.php?extdetail=EML) **Update**: Fix bug for overwrite files when received multi-message in one SMTP session.
Django's transition from oldforms to newforms is nearing. If you're using recent trunk source code from Django's subversion repository, you should start using newforms. But there are still some rough edges as of today. File uploading seems to be one of them. (Adrian and other Django folks are well aware of this. Please don't bother them by asking "Are we there yet?") The Django mailing lists and Google searching didn't turn up any best practices for this area of newforms, so I muddled through it and here's the result. I omit the urls.py code necessary to hook up the zip_upload method to a URL, but otherwise this should be complete. And if I haven't loaded this with enough caveats...please be aware this code may be obsoleted soon.
Here is a trivial way to keep your Django project in shared version control or in a public repository without exposing settings that could have security implications, and without needing to modify settings.py for your local test or production environments on checkout. This is also a way to separate development settings from production settings, or to deploy the same code on multiple servers while only changing one site-specific "dotfile."
If you want to run multiple versions of a site from the same project IE a staging version and the live one, you need two settings and urlconf files. 1. make separate copies of settings_staging.py and urls_staging.py in the project dir. 2. Change SITE_ID and ROOT_URLCONF in settings_staging.py 3. Make extra include lines in the projects urls_staging.py like the example. 4. Add urls_staging.py to applications where you need extra urls. Make them just like you would normally do urls.py Thanks to ronny for suggesting the double entries in urlconf.
If your code is under source control and you develop locally and then publish that globally, you might need to modify the settings file after each update to ensure the system paths and database settings are correct. This simple solution helps to distinguish development server from the public server. And you won't need to care about modifying files on the public server anymore. Create a file called `dev_environment.py` in your `site-packages` directory of the development server only (do not put it under source control). Then use the following lines in the beginning of your files, you want to check whether you are in the development environment. try: from dev_environment import * except: is_dev_environment = False Then for example, you can set the database settings according the environment: if is_dev_environment: DATABASE_NAME = "test" DATABASE_USER = "root" DATABASE_PASSWORD = "" else: DATABASE_NAME = "publicproject" DATABASE_USER = "projectuser" DATABASE_PASSWORD = "ahl3379ljkasd"
See __doc__ for more information.
Usage: forms.DateField(input_formats=['%d.%m.%Y'], widget=DateTextInput())
I ran into this because my development system is django on python 2.4 and I deploy to 2.3. It's a corner case where you use gettext, the \# -\*- coding: utf-8 -\*- header and want to have a consistant style in your file. It is encouraged to use the unicode marker like u'string', but this does not work for __str__ methods of your models as they are called by the ``str'' function and that function again can not handle unicode. It would be really nice to have all unicode intern and only do the appropriated encoding on the output. Anyway. With this little helper you can clutter your files with _('stirng of heart with € äüöß') ... With the coding directive in the header python 2.4 and gettext can handle this on 2.3 though they can't. So this script adds a parachut to the gettext wrapper that kicks in if gettext is failing.
Handy for things such as: `{{ some_string|slice:","|join:";" }}`
**I won't be able to debug this until tonight... so if you see this message there may still be bugs in this** This Middleware replaces the behavior of the APPEND_SLASH in the CommonMiddleware. Please set APPEND_SLASH = False if you are going to use this Middleware. Add the key defined by APPENDSLASH to the view_kwargs and a True or False to determine the behaivor of the appended slashes. For instance I set my DEFAULTBEHAVIOR to the default of True, then to override that behaivor I add 'AppendSlash':False to the URLs that I wish to have no slash. **Example** ` urlpatterns = patterns('some_site.some_app.views', (r'^test/no_append$','test_no_append',{'AppendSlash':False}), (r'^test/append/$','test_append'), ) `
**SSL Middleware** This middleware answers the problem of redirecting to (and from) a SSL secured path by stating what paths should be secured in urls.py file. To secure a path, add the additional view_kwarg 'SSL':True to the view_kwargs. For example ` urlpatterns = patterns('some_site.some_app.views', (r'^test/secure/$','test_secure',{'SSL':True}), ) ` All paths where 'SSL':False or where the kwarg of 'SSL' is not specified are routed to an unsecure path. For example ` urlpatterns = patterns('some_site.some_app.views', (r'^test/unsecure1/$','test_unsecure',{'SSL':False}), (r'^test/unsecure2/$','test_unsecure'), ) ` **Gotcha's** Redirects should only occur during GETs; this is due to the fact that POST data will get lost in the redirect. **Benefits/Reasoning** A major benefit of this approach is that it allows you to secure django.contrib views and generic views without having to modify the base code or wrapping the view. This method is also better than the two alternative approaches of adding to the settings file or using a decorator. It is better than the tactic of creating a list of paths to secure in the settings file, because you DRY. You are also not forced to consider all paths in a single location. Instead you can address the security of a path in the urls file that it is resolved in. It is better than the tactic of using a @secure or @unsecure decorator, because it prevents decorator build up on your view methods. Having a bunch of decorators makes views cumbersome to read and looks pretty redundant. Also because the all views pass through the middleware you can specify the only secure paths and the remaining paths can be assumed to be unsecure and handled by the middleware. This package is inspired by Antonio Cavedoni's SSL Middleware Notes: Updated per Jay Parlar at http://www.djangosnippets.org/snippets/240/ - Added a test for the way webfaction handles forwarded SSL requests.
Jonathan Buchanan's [Django tagging](http://code.google.com/p/django-tagging/) application is the best thing since sliced bread, and makes adding generic tagging to any model trivially easy. But you can make it just a tiny bit easier to use by setting up a property on your model for handling the tags. Once you've set this up, you can access and set tags in a fairly natural way: >>> obj = MyModel.objects.get(pk=1) >>> obj.tags = 'foo bar' >>> obj.tags [<Tag: foo>, <Tag: bar>] And remember that `obj.tags` will return a `QuerySet`, so you can do filtering on it.
**Problem:** You want to render an arbitrary number of fields assigned dynamically, as in [snippet #27](http://www.djangosnippets.org/snippets/27/), but using multiple `if` statements in a template would be tedious. **Solution:** newforms BoundField The example demonstrates a form with medication fields. We don't know in advance how many meds will be prescribed to a patient, but we want to display a minimum of 4 medication fields, each consisting of a label, name, and dosage. My code uses a cheap hack of assigning a .bf attribute to the fields during __init__, but it's easy to render in a template loop: `{% for med in form.med_list %}` *Special thanks to Honza for advice on BoundField.*
After reading the comment to my [snippet #49](http://www.djangosnippets.org/snippets/49/) it occurs to me that Python properties may not be obvious to everyone, and may be underutilized in Django models. Here is a simple example demonstrating a property to format a Person's name.
2955 snippets posted so far.