views:

54

answers:

2

If you have a date time field within the admin, and you invoke the "Today" link it seems it throws an exception from calendar.js where it references an undefined global method get_format. This doesn't seem to be defined in any of the latest admin js files.

Edit:

It seems like it was using a different i18n.py file from my standard django 1.1 on the system. Here's my wsgi file:

import os, sys, site

site.addsitedir( '/srv/python-environments/django1point2/lib/python2.5/site-packages')

sys.path.append('/srv/')
sys.path.append('/srv/workarounds')

os.environ['DJANGO_SETTINGS_MODULE'] = 'workarounds.settings'

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

What do I need to alter so it relies on the i18n.py in the addsitedir string I specify instead of my system default?

+2  A: 

The admin widget most certainly does work under normal circumstances (I've used it under Django trunk, 1.2 and 1.2.1). The question is "what's different about your situation?"

For the record, the function you're looking for is defined here.

My first thought is perhaps you modified your admin templates and the appropriate scripts are not being included. Thought number two is perhaps you have a cached version of an old file somewhere.

There were quite a lot of changes to the javascript i18n framework and localization machinery in v1.2, so it may be best to start with what settings you're using.

All in all, you're going to need to give a lot more information in order to get a useful answer.

Gabriel Hurley
you got it - it was using a different `i18n.py` file. I updated the original post with my wsgi file settings.
meder
+2  A: 

Your .wsgi code puts the virtualenv site-packages after the system site-packages, so global packages will take priority. I use the following snippet (from the mod_wsgi documentation on use with virtualenv, which I recommend) to put the virtualenv site-packages first:

ALLDIRS = [os.path.join(virtenv, 'lib',
                                 'python%s' % sys.version[:3],
                                 'site-packages')]

# Remember original sys.path.
prev_sys_path = list(sys.path)

# Add project directory
sys.path.append(project)

# Add each new site-packages directory.
for directory in ALLDIRS:
  site.addsitedir(directory)

# Reorder sys.path so new directories at the front.
new_sys_path = []
for item in list(sys.path):
    if item not in prev_sys_path:
        new_sys_path.append(item)
        sys.path.remove(item)
sys.path[:0] = new_sys_path
Carl Meyer
Thanks for providing that. Is your project's parent directory already in the sys.path? I had to do both `sys.path.append('/projectContainer')` and `sys.path.append('/projectContainer/proj`.
meder
Yes, I didn't include the part of the .wsgi file that puts the project itself on the path. Don't put both the project and its parent on sys.path, though: choose one and use it consistently. Personally I prefer not having the project name on the path, others prefer the other way.
Carl Meyer
Ensure you read 'http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html'. It covers the issues around sys.path and whether parent or project directory should be used.
Graham Dumpleton