Hackish Way to Execute on manage.py Action
It's cheap, hackish, and dirty, but it works. \\o/ Lines 19 & 20 are what you should edit.
- manage.py
- hack
It's cheap, hackish, and dirty, but it works. \\o/ Lines 19 & 20 are what you should edit.
This is a basic example for sending an email to a user (in this case, when they've signed up at a website) using the Django template framework. It's really quite simple - we're just using a plain text template instead of HTML, and using the output of the template's 'render()' method as the message body. Of course, in your project you won't blindly use data from request.POST! This example was first posted on [my blog at rossp.org](http://www.rossp.org/blog/2006/jul/11/sending-e-mails-templates/)
Intall -------- In your settings.py, set it in MIDDLEWARE_CLASSES. Default all the profile files will be save in ./profile folder(if there is no this directory, it'll automatically create one), and you can set a PROFILE_DATA_DIR option in settings.py, so that the profile files can be saved in this folder. How does it works ------------------- Record every request in a profile file. As you can see in the code: profname = "%s.prof" % (request.path.strip("/").replace('/', '.')) so if you request an url multi-times, only the last request will be saved, because previous profile files will be overriden. And you can find a commentted line, it'll save each request in different file according the time, so if you like that you can change the code. # profname = "%s.%.3f.prof" % (request.path.strip("/").replace('/', '.'), time.time()) and if you want to see the output, you can run below code, but you should change the filename value: import hotshot, hotshot.stats stats = hotshot.stats.load(filename) #stats.strip_dirs() #stats.sort_stats('time', 'calls') stats.print_stats()
Easy way to move data via XML dump in PhpMyAdmin
Finds links from a body of html so you can display them elsewhere.
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.
**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.*
This is a reasonably straight forward port of functionality provided by the `django.utils.dateformat` module into a method extending JavaScript's Date object. Its intended use is to allow client-side dynamic content to share the same date & time string formatting as Django template markup. By using this in conjunction with a context processor (to pass a format string to all templates) you can switch formats for both server-generated & client-generated dates across a complete site with a single setting. The function supports *almost* the entire format -- as listed by the Django documentation for the [now template tag](http://www.djangoproject.com/documentation/templates/#now) -- with the exception of "I" & "T". As a 'dumb' illustration, the following template tag usage: It is {% now "jS F Y H:i" %} ...could equate to the following: It is <script type="text/javascript">var now = new Date(); document.write(now.strfdate('jS F Y H:i'));</script> It's not extensively tested (I only wrote it over the weekend), but seems to be working okay. Feel free to leave any corrections or suggestions in the comments, and I'll try to keep this entry updated if I make any fixes or changes.
**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'), ) `
Handy for things such as: `{{ some_string|slice:","|join:";" }}`
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.
Usage: forms.DateField(input_formats=['%d.%m.%Y'], widget=DateTextInput())
See __doc__ for more information.
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"
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.