Re: I install v1.5 Django, and run a my first site, then have an error: 'utf-8' codec can't decode byte 0xbc in position 0: invalid start byte. I use Sublime editor.

[Julien Phalip]

Hi,

Can you please post the entire traceback?

Thanks!

Julien

On Sunday, November 25, 2012 4:03:11 PM UTC+1, 名宏贾 wrote:
>
>  I don't know why, editer have default utf-8 setting.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/IO1GwuMHLXQJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Validating a specific model field

[Julien Phalip]

Hi,

It's the first time I'm playing with model validation, and I'm a bit
stuck with something. I couldn't find any help on this mailinglist or
in the doc, but if there is please let me know where :)

Basically I'd like to validate a model field in the context of its
instance. First I assumed it would work like with form validation, so
I did:

class Title(models.Model):
is_video = models.BooleanField(...)
aspect_ratio = models.CharField(...)
...

clean_aspect_ratio(self, value):
if self.is_video is True and value == '':
raise ValidationError('The aspect ratio is required for
video titles.')

But this doesn't work. The 'clean_aspect_ratio' method is never
called. I could use validators, but from there I can't have access to
the model instance and therefore I can't access the 'is_video'
attribute. It sort of works with the 'clean' method:

class Title(models.Model):
...

clean(self):
if self.is_video and value == '':
raise ValidationError('The aspect ratio is required for
video titles.')

However, this error is not attached specifically to the 'aspect_ratio'
attribute, therefore the error is displayed at the top of the admin
form rather than next to the aspect_ratio form field.

Is there a way to achieve the same type of specific validation like
with forms?

Many thanks,

Julien

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Weird transaction problem with postgresql

[Julien Phalip]

Hi,

After looking through this mailing list I've seen many threads
discussing issues relating to transaction issues with postgresql, but
none like the one I'm facing. If I've missed any relevant thread,
please let me know.

I've got a Profile model which is instantiated each time a new user is
created:

from models import Profile

def create_profile_for_user(sender, instance, signal, created,
*args, **kwargs):
if kwargs['raw'] == False: # Test if we're not loading
fixtures
if created:
profile = Profile(user=instance)
profile.save()

signals.post_save.connect(create_profile_for_user, sender=User)

But when I try to create a new user from the admin, it crashes with
the following traceback:

File "/home/myuser/.virtualenvs/mysite/src/django/django/core/handlers/
base.py" in get_response
  101. response = callback(request,
*callback_args, **callback_kwargs)
File "/home/myuser/.virtualenvs/mysite/src/django/django/contrib/admin/
options.py" in wrapper
  240. return self.admin_site.admin_view(view)(*args,
**kwargs)
File "/home/myuser/.virtualenvs/mysite/src/django/django/utils/
decorators.py" in _wrapped_view
  68. response = view_func(request, *args,
**kwargs)
File "/home/myuser/.virtualenvs/mysite/src/django/django/views/
decorators/cache.py" in _wrapped_view_func
  69. response = view_func(request, *args, **kwargs)
File "/home/myuser/.virtualenvs/mysite/src/django/django/contrib/admin/
sites.py" in inner
  194. return view(request, *args, **kwargs)
File "/home/myuser/.virtualenvs/mysite/src/django/django/utils/
decorators.py" in _wrapper
  21. return decorator(bound_func)(*args, **kwargs)
File "/home/myuser/.virtualenvs/mysite/src/django/django/utils/
decorators.py" in _wrapped_view
  68. response = view_func(request, *args,
**kwargs)
File "/home/myuser/.virtualenvs/mysite/src/django/django/utils/
decorators.py" in bound_func
  17. return func(self, *args2, **kwargs2)
File "/home/myuser/.virtualenvs/mysite/src/django/django/db/
transaction.py" in _commit_on_success
  295. res = func(*args, **kw)
File "/home/myuser/.virtualenvs/mysite/src/django/django/contrib/auth/
admin.py" in add_view
  104. return super(UserAdmin, self).add_view(request,
form_url, extra_context)
File "/home/myuser/.virtualenvs/mysite/src/django/django/utils/
decorators.py" in _wrapper
  21. return decorator(bound_func)(*args, **kwargs)
File "/home/myuser/.virtualenvs/mysite/src/django/django/utils/
decorators.py" in _wrapped_view
  68. response = view_func(request, *args,
**kwargs)
File "/home/myuser/.virtualenvs/mysite/src/django/django/utils/
decorators.py" in bound_func
  17. return func(self, *args2, **kwargs2)
File "/home/myuser/.virtualenvs/mysite/src/django/django/db/
transaction.py" in _commit_on_success
  306. leave_transaction_management(using=using)
File "/home/myuser/.virtualenvs/mysite/src/django/django/db/
transaction.py" in leave_transaction_management
  87. raise TransactionManagementError("Transaction managed
block ended with pending COMMIT/ROLLBACK")

Exception Type: TransactionManagementError at /admin/auth/user/add/
Exception Value: Transaction managed block ended with pending COMMIT/
ROLLBACK


My database settings are as follows:

DATABASES = {
'default': {
'NAME': 'mydb',
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'USER': 'myuser',
'PASSWORD': 'secret',
}
}

I've also tried to add 'OPTIONS': { "autocommit": True, } (following
the recommendation in 
http://docs.djangoproject.com/en/dev/ref/databases/#autocommit-mode)
but I still get the same error.

Disconnecting the create_profile_for_user signal makes it work (but
obviously no Profile object is instantiated).

The weird thing is that everything works fine with Sqlite. So it's
typically a postgresql issue. I'm using psql version 8.3.1 and a
recent checkout of Django trunk.

Any help would be very welcome, as I'm really baffled here.

Many thanks!

Regards,

Julien

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: MySQL and 'NoneType object is unsubscriptable' error

[Julien Phalip]

On Nov 11, 10:07 am, Julien Phalip <jpha...@gmail.com> wrote:
> On Nov 11, 9:37 am, Julien Phalip <jpha...@gmail.com> wrote:
>
>
>
> > On Nov 10, 9:12 pm, Daniel Roseman <dan...@roseman.org.uk> wrote:
>
> > > On Nov 10, 1:36 am, Julien Phalip <jpha...@gmail.com> wrote:
>
> > > > Hi,
>
> > > > I've tried to install MySQL for an existing project, and I'm getting a
> > > > strange error (see traceback below). Apparently "self.converter" is
> > > > None, but I can't see why.
>
> > > > I can access the database just fine using the 'mysql' command in the
> > > > terminal or using PhpMyAdmin.
>
> > > > Do you know how this could be fixed?
>
> > > > Thanks a lot for you help.
>
> > > > Julien
>
> > > > Traceback (most recent call last):
> > > >   File "/Users/julien/Documents/Development/eclipse/workspace/
> > > > myproject/trunk/site/manage.py", line 13, in 
> > > >     execute_manager(settings)
> > > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > > django/core/management/__init__.py", line 439, in execute_manager
> > > >     utility.execute()
> > > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > > django/core/management/__init__.py", line 380, in execute
> > > >     self.fetch_command(subcommand).run_from_argv(self.argv)
> > > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > > django/core/management/base.py", line 195, in run_from_argv
> > > >     self.execute(*args, **options.__dict__)
> > > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > > django/core/management/base.py", line 222, in execute
> > > >     output = self.handle(*args, **options)
> > > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > > django/core/management/commands/runserver.py", line 84, in handle
> > > >     inner_run()
> > > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > > django/core/management/commands/runserver.py", line 48, in inner_run
> > > >     self.validate(display_num_errors=True)
> > > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > > django/core/management/base.py", line 249, in validate
> > > >     num_errors = get_validation_errors(s, app)
> > > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > > django/core/management/validation.py", line 67, in
> > > > get_validation_errors
> > > >     connection.validation.validate_field(e, opts, f)
> > > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > > django/db/backends/mysql/validation.py", line 15, in validate_field
> > > >     db_version = connection.get_server_version()
> > > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > > django/db/backends/mysql/base.py", line 297, in get_server_version
> > > >     self.cursor()
> > > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > > django/db/backends/__init__.py", line 81, in cursor
> > > >     cursor = self._cursor()
> > > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > > django/db/backends/mysql/base.py", line 281, in _cursor
> > > >     self.connection = Database.connect(**kwargs)
> > > >   File "/opt/local/lib/python2.5/site-packages/MySQLdb/__init__.py",
> > > > line 81, in Connect
> > > >     return Connection(*args, **kwargs)
> > > >   File "/opt/local/lib/python2.5/site-packages/MySQLdb/
> > > > connections.py", line 222, in __init__
> > > >     self.converter[FIELD_TYPE.STRING].append((None, string_decoder))
> > > > TypeError: 'NoneType' object is unsubscriptable
>
> > > Looks like a problem with your database connection settings. Can you
> > > post the relevant bits from settings.py?
> > > --
> > > DR.
>
> > Hi Daniel,
>
> > Thanks for your reply. The settings seem to be fine I think:
>
> > DATABASE_ENGINE = 'mysql'           # 'postgresql', 'mysql', 'sqlite3'
> > or 'ado_mssql'.
> > DATABASE_NAME = 'testd

Re: MySQL and 'NoneType object is unsubscriptable' error

[Julien Phalip]

On Nov 11, 9:37 am, Julien Phalip <jpha...@gmail.com> wrote:
> On Nov 10, 9:12 pm, Daniel Roseman <dan...@roseman.org.uk> wrote:
>
>
>
> > On Nov 10, 1:36 am, Julien Phalip <jpha...@gmail.com> wrote:
>
> > > Hi,
>
> > > I've tried to install MySQL for an existing project, and I'm getting a
> > > strange error (see traceback below). Apparently "self.converter" is
> > > None, but I can't see why.
>
> > > I can access the database just fine using the 'mysql' command in the
> > > terminal or using PhpMyAdmin.
>
> > > Do you know how this could be fixed?
>
> > > Thanks a lot for you help.
>
> > > Julien
>
> > > Traceback (most recent call last):
> > >   File "/Users/julien/Documents/Development/eclipse/workspace/
> > > myproject/trunk/site/manage.py", line 13, in 
> > >     execute_manager(settings)
> > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > django/core/management/__init__.py", line 439, in execute_manager
> > >     utility.execute()
> > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > django/core/management/__init__.py", line 380, in execute
> > >     self.fetch_command(subcommand).run_from_argv(self.argv)
> > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > django/core/management/base.py", line 195, in run_from_argv
> > >     self.execute(*args, **options.__dict__)
> > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > django/core/management/base.py", line 222, in execute
> > >     output = self.handle(*args, **options)
> > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > django/core/management/commands/runserver.py", line 84, in handle
> > >     inner_run()
> > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > django/core/management/commands/runserver.py", line 48, in inner_run
> > >     self.validate(display_num_errors=True)
> > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > django/core/management/base.py", line 249, in validate
> > >     num_errors = get_validation_errors(s, app)
> > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > django/core/management/validation.py", line 67, in
> > > get_validation_errors
> > >     connection.validation.validate_field(e, opts, f)
> > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > django/db/backends/mysql/validation.py", line 15, in validate_field
> > >     db_version = connection.get_server_version()
> > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > django/db/backends/mysql/base.py", line 297, in get_server_version
> > >     self.cursor()
> > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > django/db/backends/__init__.py", line 81, in cursor
> > >     cursor = self._cursor()
> > >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > > django/db/backends/mysql/base.py", line 281, in _cursor
> > >     self.connection = Database.connect(**kwargs)
> > >   File "/opt/local/lib/python2.5/site-packages/MySQLdb/__init__.py",
> > > line 81, in Connect
> > >     return Connection(*args, **kwargs)
> > >   File "/opt/local/lib/python2.5/site-packages/MySQLdb/
> > > connections.py", line 222, in __init__
> > >     self.converter[FIELD_TYPE.STRING].append((None, string_decoder))
> > > TypeError: 'NoneType' object is unsubscriptable
>
> > Looks like a problem with your database connection settings. Can you
> > post the relevant bits from settings.py?
> > --
> > DR.
>
> Hi Daniel,
>
> Thanks for your reply. The settings seem to be fine I think:
>
> DATABASE_ENGINE = 'mysql'           # 'postgresql', 'mysql', 'sqlite3'
> or 'ado_mssql'.
> DATABASE_NAME = 'testdb'             # Or path to database file if
> using sqlite3.
> DATABASE_USER = 'root'             # Not used with sqlite3.
> DATABASE_PASSWORD = ''         # Not used with sqlite3.
> DATABASE_HOST = ''             # Set to empty string for localhost.
> Not used with sqlite3.
> DATABASE_PORT = ''             # Set to empty string for default. Not
> used with sqlite3.
>
> I've never come

Re: MySQL and 'NoneType object is unsubscriptable' error

[Julien Phalip]

On Nov 10, 9:12 pm, Daniel Roseman <dan...@roseman.org.uk> wrote:
> On Nov 10, 1:36 am, Julien Phalip <jpha...@gmail.com> wrote:
>
>
>
> > Hi,
>
> > I've tried to install MySQL for an existing project, and I'm getting a
> > strange error (see traceback below). Apparently "self.converter" is
> > None, but I can't see why.
>
> > I can access the database just fine using the 'mysql' command in the
> > terminal or using PhpMyAdmin.
>
> > Do you know how this could be fixed?
>
> > Thanks a lot for you help.
>
> > Julien
>
> > Traceback (most recent call last):
> >   File "/Users/julien/Documents/Development/eclipse/workspace/
> > myproject/trunk/site/manage.py", line 13, in 
> >     execute_manager(settings)
> >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > django/core/management/__init__.py", line 439, in execute_manager
> >     utility.execute()
> >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > django/core/management/__init__.py", line 380, in execute
> >     self.fetch_command(subcommand).run_from_argv(self.argv)
> >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > django/core/management/base.py", line 195, in run_from_argv
> >     self.execute(*args, **options.__dict__)
> >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > django/core/management/base.py", line 222, in execute
> >     output = self.handle(*args, **options)
> >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > django/core/management/commands/runserver.py", line 84, in handle
> >     inner_run()
> >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > django/core/management/commands/runserver.py", line 48, in inner_run
> >     self.validate(display_num_errors=True)
> >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > django/core/management/base.py", line 249, in validate
> >     num_errors = get_validation_errors(s, app)
> >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > django/core/management/validation.py", line 67, in
> > get_validation_errors
> >     connection.validation.validate_field(e, opts, f)
> >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > django/db/backends/mysql/validation.py", line 15, in validate_field
> >     db_version = connection.get_server_version()
> >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > django/db/backends/mysql/base.py", line 297, in get_server_version
> >     self.cursor()
> >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > django/db/backends/__init__.py", line 81, in cursor
> >     cursor = self._cursor()
> >   File "/Users/julien/Documents/Development/eclipse/workspace/django/
> > django/db/backends/mysql/base.py", line 281, in _cursor
> >     self.connection = Database.connect(**kwargs)
> >   File "/opt/local/lib/python2.5/site-packages/MySQLdb/__init__.py",
> > line 81, in Connect
> >     return Connection(*args, **kwargs)
> >   File "/opt/local/lib/python2.5/site-packages/MySQLdb/
> > connections.py", line 222, in __init__
> >     self.converter[FIELD_TYPE.STRING].append((None, string_decoder))
> > TypeError: 'NoneType' object is unsubscriptable
>
> Looks like a problem with your database connection settings. Can you
> post the relevant bits from settings.py?
> --
> DR.

Hi Daniel,

Thanks for your reply. The settings seem to be fine I think:

DATABASE_ENGINE = 'mysql'   # 'postgresql', 'mysql', 'sqlite3'
or 'ado_mssql'.
DATABASE_NAME = 'testdb' # Or path to database file if
using sqlite3.
DATABASE_USER = 'root' # Not used with sqlite3.
DATABASE_PASSWORD = '' # Not used with sqlite3.
DATABASE_HOST = '' # Set to empty string for localhost.
Not used with sqlite3.
DATABASE_PORT = '' # Set to empty string for default. Not
used with sqlite3.

I've never come across that error before. And this code used to work
when I run it some months ago... I'm really at a loss here.

Thanks,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

MySQL and 'NoneType object is unsubscriptable' error

[Julien Phalip]

Hi,

I've tried to install MySQL for an existing project, and I'm getting a
strange error (see traceback below). Apparently "self.converter" is
None, but I can't see why.

I can access the database just fine using the 'mysql' command in the
terminal or using PhpMyAdmin.

Do you know how this could be fixed?

Thanks a lot for you help.

Julien


Traceback (most recent call last):
  File "/Users/julien/Documents/Development/eclipse/workspace/
myproject/trunk/site/manage.py", line 13, in 
execute_manager(settings)
  File "/Users/julien/Documents/Development/eclipse/workspace/django/
django/core/management/__init__.py", line 439, in execute_manager
utility.execute()
  File "/Users/julien/Documents/Development/eclipse/workspace/django/
django/core/management/__init__.py", line 380, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Users/julien/Documents/Development/eclipse/workspace/django/
django/core/management/base.py", line 195, in run_from_argv
self.execute(*args, **options.__dict__)
  File "/Users/julien/Documents/Development/eclipse/workspace/django/
django/core/management/base.py", line 222, in execute
output = self.handle(*args, **options)
  File "/Users/julien/Documents/Development/eclipse/workspace/django/
django/core/management/commands/runserver.py", line 84, in handle
inner_run()
  File "/Users/julien/Documents/Development/eclipse/workspace/django/
django/core/management/commands/runserver.py", line 48, in inner_run
self.validate(display_num_errors=True)
  File "/Users/julien/Documents/Development/eclipse/workspace/django/
django/core/management/base.py", line 249, in validate
num_errors = get_validation_errors(s, app)
  File "/Users/julien/Documents/Development/eclipse/workspace/django/
django/core/management/validation.py", line 67, in
get_validation_errors
connection.validation.validate_field(e, opts, f)
  File "/Users/julien/Documents/Development/eclipse/workspace/django/
django/db/backends/mysql/validation.py", line 15, in validate_field
db_version = connection.get_server_version()
  File "/Users/julien/Documents/Development/eclipse/workspace/django/
django/db/backends/mysql/base.py", line 297, in get_server_version
self.cursor()
  File "/Users/julien/Documents/Development/eclipse/workspace/django/
django/db/backends/__init__.py", line 81, in cursor
cursor = self._cursor()
  File "/Users/julien/Documents/Development/eclipse/workspace/django/
django/db/backends/mysql/base.py", line 281, in _cursor
self.connection = Database.connect(**kwargs)
  File "/opt/local/lib/python2.5/site-packages/MySQLdb/__init__.py",
line 81, in Connect
return Connection(*args, **kwargs)
  File "/opt/local/lib/python2.5/site-packages/MySQLdb/
connections.py", line 222, in __init__
self.converter[FIELD_TYPE.STRING].append((None, string_decoder))
TypeError: 'NoneType' object is unsubscriptable
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Replicating Google Groups in Django

[Julien Phalip]

Thank you Clifford and all for your tips. There are apparently a few
options to explore. I'll give them a shot and see how far I get.

Cheers!

Julien

On Oct 25, 4:35 am, CLIFFORD ILKAY  wrote:
> Preston Holmes wrote:
> > It doesn't seem like it would be that hard to combine django-
> > extensions export_emails command with Mailmans sync_members script
> > inside a cron job or a URL triggered script.
>
> > Usage: /usr/share/mailman/bin/sync_members [options] -f file listname
>
> If users can manage their Mailman subscriptions via email or the MM web
> interface, using the sync_members approach, just like trying to
> "automate" MM by "calling" the email or web interface, can be
> problematic. How is Django supposed to know if a subscriber changed some
> options in MM, for example, setting themselves to NOMAIL? This approach
> is uni-directional and to make it bi-directional, you'll have to
> replicate a good part of the Mailman web front-end. The easiest and most
> robust approach is to have Mailman store its configuration in a SQL
> database instead of Python pickles and have Django connect to the same
> database.
>
> Another option, and one that I hadn't mentioned in my previous posts, is
> to forget about using Mailman and use something like Sympa, which offers
> a SOAP interface. It was designed from the outset to integrate with
> other things whereas Mailman is quite monolithic, which makes for a
> challenging integration.
> --
> Regards,
>
> Clifford Ilkay
> Dinamis
> 1419-3266 Yonge St.
> Toronto, ON
> Canada  M4N 3P6
>
> 
> +1 416-410-3326
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Replicating Google Groups in Django

[Julien Phalip]

Hi,

On one site I'm considering the possibility of replicating the (basic)
functionality of Google Groups in Django. The idea is:

- There would be 5 different mailing lists. Users can subscribe to one
or more lists.
- People can purely use emails to access the lists.
- All the emails can then also be seen via a web interface.

I've been thinking of using Mailman to leverage all the email
management part. But now I'm not sure how to reliably sync the Mailman
subscription system with django.contrib.auth.

I don't think there's any straight forward to do this. Would you have
any advice to get me started?

Thanks!

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Strange error saving in admin

[Julien Phalip]

Hi,

I've got a really strange error on one of my sites. There is an
Organisation model which has a dozen of fields and 1,300 rows.

Saving organisation details in the admin usually works fine except for
one organisation. When I click 'Save', the page loads for ever and
then it fails with a 502 Proxy Error. I can edit the corresponding row
in Phpmyadmin without any problem so the database doesn't seem to be
damaged. Saving works with all other organisations I've tested.

It is using Django revision 9975.

Would you have any tips for debugging this?

Thanks a lot!

Regards,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

How to delete a setting

[Julien Phalip]

Hi,

In a unit test, I'd like to test the behaviour of a middleware in the
absence of a setting. To make sure the setting is not present, I try
to delete it:

def test_middleware(self):
if hasattr(settings, 'BLAH'):
delattr(settings, 'BLAH')
response = self.client.get('/')
...

However, if the setting BLAH exists, the call to delattr returns an
"Attribute error: BLAH" error.

I'm wondering if that's because the settings are lazily loaded. BTW,
I'm using Python 2.5.

Do you have a tip on how I could achieve this?

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Strange issue with session not being saved

[Julien Phalip]

On Apr 13, 9:43 am, Julien Phalip <jpha...@gmail.com> wrote:
> Hi,
>
> I've implemented and ajax upload progress bar and I've got a strange
> issue with sessions. I've reused the exact same code from another
> project where it works perfectly, so I assume there is some kind of
> configuration problem. Any hint on how to debug this would be very
> welcome.
>
> Basically, the way it works is that a custom upload handler updates a
> session entry with the progress of the upload as new chunks of a big
> file are received. In parallel, an ajax request is periodically sent
> to fetch the session entry and update the progress bar in the
> frontend.
>
> However, the problem is that the session entry is not saved until the
> file has finished being uploaded. Whenever the ajax requests are sent
> the new session entry is not accessible at all. It doesn't seem to be
> saved.
>
> I've tried to set the "SESSION_SAVE_EVERY_REQUEST = False" setting,
> and I also tried to set "request.session.modified = True" right before
> saving the session entry. But that didn't make a difference. Both the
> upload and ajax requests use the same domain. Both projects (the one
> that works and the one that doesn't) use MySQL.
>
> Could that be a problem in Django's or Apache configurations?

Hello again,

My colleague has found something interesting in the error logs on the
server:

2009/04/12 01:21:19 [warn] 23290#0: *101972 a client request body is
buffered to a temporary file /usr/local/nginx/client_body_temp/
05, client: 115.64.36.192, server: my.domain.com, request:
"POST /tester/?X-Progress-ID=1914b38e-272a-11de-92cd-00221924bc8a HTTP/
1.1", host: "my.domain.com", referrer: "http://my.domain.com/tester/;

It seems like Nginx is messing things up. (BTW, Nginx is not set up on
the server of the project that works, but it is set up on the project
that doesn't work).

Does it mean that Nginx, as it is currently configured, may prevent
multiple POST requests to be processed at the same time?

Thanks a lot!

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Strange issue with session not being saved

[Julien Phalip]

Hi,

I've implemented and ajax upload progress bar and I've got a strange
issue with sessions. I've reused the exact same code from another
project where it works perfectly, so I assume there is some kind of
configuration problem. Any hint on how to debug this would be very
welcome.

Basically, the way it works is that a custom upload handler updates a
session entry with the progress of the upload as new chunks of a big
file are received. In parallel, an ajax request is periodically sent
to fetch the session entry and update the progress bar in the
frontend.

However, the problem is that the session entry is not saved until the
file has finished being uploaded. Whenever the ajax requests are sent
the new session entry is not accessible at all. It doesn't seem to be
saved.

I've tried to set the "SESSION_SAVE_EVERY_REQUEST = False" setting,
and I also tried to set "request.session.modified = True" right before
saving the session entry. But that didn't make a difference. Both the
upload and ajax requests use the same domain. Both projects (the one
that works and the one that doesn't) use MySQL.

Could that be a problem in Django's or Apache configurations?

Any help would be much appreciated :)

Thanks!

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Strange behaviour with ImageField

[Julien Phalip]

On Mar 26, 4:42 pm, Michael Strickland  wrote:
> You should just be able to take out the MEDIA_ROOT portion of your
> upload_to path. So instead of:
>     upload_to='%s/images/' % settings.MEDIA_ROOT
> You would have:
>     upload_to='images/'
>
> That should make it store the relative address and not the absolute
> address in your database.
>
> As for {{photo.image_file.url}} generating the absolute address
> instead of the correct url, double-check your "MEDIA_URL" string in
> your main settings file. It should be set to something like 
> 'http://www.example.com/media/'or 'http://www.example.com/site-media/', and
> should definitely be different than you "MEDIA_ROOT" setting.

Taking out MEDIA_ROOT from the upload_to argument did the trick. Thank
you Michael!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Strange behaviour with ImageField

[Julien Phalip]

Hi,

Sorry if my question seems trivial, but I've looked around for an
answer and I'm really at loss...

I've got a simple model:

class Photo(models.Model):
image_file = models.ImageField(_('image file'), upload_to='%s/
images/' % settings.MEDIA_ROOT)

But when I upload an image via the admin it saves the whole path into
'image_file' (e.g. '/home/blah/media/images/example.gif'). Shouldn't
it just save the relative path (e.g. 'images/example.gif')?

The problem is that if in a template I do:



... it generates the following:



I'm using a fresh checkout of Django from today. I tested both on
windows and on a Linux server.

Thanks a lot,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Auth (or session?) issue and www prefix

[Julien Phalip]

On Mar 26, 11:55 am, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> On Mar 26, 11:04 am, Julien Phalip <jpha...@gmail.com> wrote:
>
> > Hi there,
>
> > If I login on my site on example.com, and then visitwww.example.com
> > it asks me to login again. I can't tell if it's an issue with
> > contrib.auth or contrib.session, or if that's a problem with my Apache
> > configuration. My guess is that the session/cookies are not shared
> > betweenwww.example.comandexample.com.
>
> > It does that on all the sites I manage. So I wonder if I've badly
> > configured them all, or if that's a bug. If the latter, is there a
> > ticket open for it? I couldn't find any tip either in the doc or in
> > the bug tracker.
>
> Try:
>
>  http://docs.djangoproject.com/en/dev/ref/settings/#session-cookie-domain
>
> Graham

Awesome! Thank you Graham!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Auth (or session?) issue and www prefix

[Julien Phalip]

Hi there,

If I login on my site on example.com, and then visit www.example.com
it asks me to login again. I can't tell if it's an issue with
contrib.auth or contrib.session, or if that's a problem with my Apache
configuration. My guess is that the session/cookies are not shared
between www.example.com and example.com.

It does that on all the sites I manage. So I wonder if I've badly
configured them all, or if that's a bug. If the latter, is there a
ticket open for it? I couldn't find any tip either in the doc or in
the bug tracker.

Thanks a lot,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Possible bug in admin?

[Julien Phalip]

On Mar 5, 2:40 pm, Alex Gaynor <alex.gay...@gmail.com> wrote:
> On Mar 4, 2009, at 10:33 PM, Julien Phalip <jpha...@gmail.com> wrote:
>
>
>
>
>
> > On Mar 5, 2:16 pm, Alex Gaynor <alex.gay...@gmail.com> wrote:
> >> On 3/4/09, Julien Phalip <jpha...@gmail.com> wrote:
> >>> Hi,
>
> >>> I can't find the exact cause of this, but it seems as though  
> >>> something
> >>> has changed in the admin's email widget.
>
> >>> For one of my project I just upgraded Django from revision 9294 to
> >>> 9975.
>
> >>> Symptomatically, with the recent version, the email field doesn't  
> >>> have
> >>> the CSS class 'vTextField', which means it looks smaller than the
> >>> other text fields in the form.
>
> >>> Do you know if that's by design or if that's an oversight?
>
> >>> For now, a quick fix is to do something like this in my code:
>
> >>> class MyModelAdmin(ModelAdmin):
>
> >>>     def formfield_for_dbfield(self, db_field, **kwargs):
> >>>         if db_field.attname == 'email':
> >>>             kwargs['widget'] = AdminTextInputWidget() # Have to do
> >>> that, otherwise the email field is bizarrely small (it doesn't have
> >>> the 'vTextField' class)...
> >>>         return super(MyModelAdmin, self).formfield_for_dbfield
> >>> (db_field, **kwargs)
>
> >>> Thanks a lot,
>
> >>> Julien
>
> >> It's a suckasding issue. There is a ticket with a patch open about  
> >> it.
>
> >> Alex
>
> > Hi Alex,
>
> > I did search the ticket system and this list before posting but
> > couldn't find any reference to this issue. Would be great if you could
> > point me out to which ticket it is.
>
> > Thanks a lot,
>
> > Julien
>
> Unfortunately I'm on a horrible setup right now but if you check for  
> tickets assigned to me(Alex) it should jump out.
>
> Alex

Ok, thanks. I assume it's #10059.

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Possible bug in admin?

[Julien Phalip]

On Mar 5, 2:16 pm, Alex Gaynor <alex.gay...@gmail.com> wrote:
> On 3/4/09, Julien Phalip <jpha...@gmail.com> wrote:
> > Hi,
>
> > I can't find the exact cause of this, but it seems as though something
> > has changed in the admin's email widget.
>
> > For one of my project I just upgraded Django from revision 9294 to
> > 9975.
>
> > Symptomatically, with the recent version, the email field doesn't have
> > the CSS class 'vTextField', which means it looks smaller than the
> > other text fields in the form.
>
> > Do you know if that's by design or if that's an oversight?
>
> > For now, a quick fix is to do something like this in my code:
>
> > class MyModelAdmin(ModelAdmin):
>
> >     def formfield_for_dbfield(self, db_field, **kwargs):
> >         if db_field.attname == 'email':
> >             kwargs['widget'] = AdminTextInputWidget() # Have to do
> > that, otherwise the email field is bizarrely small (it doesn't have
> > the 'vTextField' class)...
> >         return super(MyModelAdmin, self).formfield_for_dbfield
> > (db_field, **kwargs)
>
> > Thanks a lot,
>
> > Julien
>
> It's a suckasding issue. There is a ticket with a patch open about it.
>
> Alex


Hi Alex,

I did search the ticket system and this list before posting but
couldn't find any reference to this issue. Would be great if you could
point me out to which ticket it is.

Thanks a lot,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Possible bug in admin?

[Julien Phalip]

Hi,

I can't find the exact cause of this, but it seems as though something
has changed in the admin's email widget.

For one of my project I just upgraded Django from revision 9294 to
9975.

Symptomatically, with the recent version, the email field doesn't have
the CSS class 'vTextField', which means it looks smaller than the
other text fields in the form.

Do you know if that's by design or if that's an oversight?

For now, a quick fix is to do something like this in my code:

class MyModelAdmin(ModelAdmin):

def formfield_for_dbfield(self, db_field, **kwargs):
if db_field.attname == 'email':
kwargs['widget'] = AdminTextInputWidget() # Have to do
that, otherwise the email field is bizarrely small (it doesn't have
the 'vTextField' class)...
return super(MyModelAdmin, self).formfield_for_dbfield
(db_field, **kwargs)

Thanks a lot,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Strange 404 error in admin

[Julien Phalip]

On Feb 10, 3:19 pm, Karen Tracey <kmtra...@gmail.com> wrote:
> On Mon, Feb 9, 2009 at 4:17 PM, Julien Phalip <jpha...@gmail.com> wrote:
> > Hello again,
>
> > I finally fixed it with the following nasty hack:
>
> > class Entry(models.Model):
> >        ... some fields ...
>
> >         objects = models.Manager() # Nasty hack
> >        published = PublishedEntryManager()
>
> > It seems like the 'change_state' view uses the custom manager instead
> > of the default one. Explicitly setting 'objects' make it work. If you
> > can think of a more elegant fix, please let me know ;)
>
> ? The first manager declared IS the default manager, so if the first and
> only manager you had declared was the restrictive one, that was the default,
> so that is what was used.  Declaring an unrestricted manager first, as you
> have done, is the documented way to have an unrestricted default manager
> plus one or more custom more restrictive managers.

I just checked out the doc again, and I had indeed missed that part on
the order of managers. Thank you Karen for the pointer.

What I found confusing though, is that the "change list" view
displayed *all* entries, including the unpublished ones. So that view
supposedly didn't use the one and only, restrictive, manager that I
had defined. As opposed to the "change object" view which apparently
made use of that restrictive manager. In effect, the unpublished
entries were listed but when you clicked on them you got that 404
page. Had the unpublished entries not showed up at all (including in
the change list) I would have thought of an issue with managers
earlier.

Because it's an old version of Django, and not even a official
release, that might just be a bug which was then fixed at a later
stage.

Regards,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Strange 404 error in admin

[Julien Phalip]

On Feb 10, 7:52 am, Julien Phalip <jpha...@gmail.com> wrote:
> On Feb 10, 7:41 am, Alex Gaynor <alex.gay...@gmail.com> wrote:
>
> > I don't know what manager old forms admin used, but do you have a custom
> > manager that blocks access to some objects.
>
> Thanks Alex for your reply. You've made a really good point which
> helped me track this down. Here are the model and manager:
>
> class PublishedEntryManager(models.Manager):
>         def get_query_set(self):
>                 return super(PublishedEntryManager, 
> self).get_query_set().filter
> (pub_date__lte=datetime.now)
>
> class Entry(models.Model):
>         ... some fields ...
>         pub_date = models.DateTimeField()
>
>         published = PublishedEntryManager()
>
> In fact, if an entry has a pub_date set in the future, then it is not
> accessible in the admin. Somehow the admin seems to be using the
> PublishedEntryManager as default manager. Is there a way to force the
> admin to use the default manager?
>
> Thanks again,
>
> Julien

Hello again,

I finally fixed it with the following nasty hack:

class Entry(models.Model):
... some fields ...

objects = models.Manager() # Nasty hack
published = PublishedEntryManager()

It seems like the 'change_state' view uses the custom manager instead
of the default one. Explicitly setting 'objects' make it work. If you
can think of a more elegant fix, please let me know ;)

Regards,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Strange 404 error in admin

[Julien Phalip]

On Feb 10, 7:41 am, Alex Gaynor  wrote:
> I don't know what manager old forms admin used, but do you have a custom
> manager that blocks access to some objects.

Thanks Alex for your reply. You've made a really good point which
helped me track this down. Here are the model and manager:

class PublishedEntryManager(models.Manager):
def get_query_set(self):
return super(PublishedEntryManager, self).get_query_set().filter
(pub_date__lte=datetime.now)

class Entry(models.Model):
... some fields ...
pub_date = models.DateTimeField()

published = PublishedEntryManager()

In fact, if an entry has a pub_date set in the future, then it is not
accessible in the admin. Somehow the admin seems to be using the
PublishedEntryManager as default manager. Is there a way to force the
admin to use the default manager?

Thanks again,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Strange 404 error in admin

[Julien Phalip]

On Feb 9, 7:20 pm, Julien Phalip <jpha...@gmail.com> wrote:
> Hi,
>
> This is a strange case. I have a simple blog entry model which can be
> edited in the admin, from the URL that looks 
> like:http://www.example.com.au/admin/blog/entry/52/
>
> Now, what is strange is that the link above returns a 404. Same with
> the entry id=51. Yet, entries with id=51,52 do exist.
>
> - All other entries (with id < 51) work fine in the admin.
> - All entries (including id=51,52) work fine on the front end.
> - Everything works fine when I test it locally on my computer with a
> replica of the online database.
>
> I've never come across something like that, and I'm not sure where to
> look to debug this. Would you have some hints to suggest?
>
> Thanks a lot for your help,
>
> Julien
>
> PS: It is using a quite old version of Django, a trunk revision
> between 0.96 and 1.0.

Hi,

I've narrowed down the issue a bit. First, it's using revision 7901,
that is before newforms-admin.
The problem is in the 'change_stage' view:

def change_stage(request, app_label, model_name, object_id):
...
try:
manipulator = model.ChangeManipulator(object_id)
except model.DoesNotExist:
raise Http404('%s object with primary key %r does not exist' %
(model_name, escape(object_id)))
...

When retrieving the manipulator it raises a 'DoesNotExist' exception:

str: Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Djangos\catalyst\django\db\models\manipulators.py", line
260, in __init__
self.original_object = self.manager.get(pk=obj_key)
  File "C:\Djangos\catalyst\django\db\models\manager.py", line 82, in
get
return self.get_query_set().get(*args, **kwargs)
  File "C:\Djangos\catalyst\django\db\models\query.py", line 294, in
get
% self.model._meta.object_name)
DoesNotExist: Entry matching query does not exist.

But I only get that with those two Entry items (id=51,52). Why don't I
get it for the other items (id < 51)?

I'm really lost here. There must be some kind of corruption in the
data meaning it cannot find those particular items, but what could it
be? Again, those 2 blog entries work fine when displayed in the
frontend.

Do you think it could be a bug in that particular revision of Django
I'm using?

Any help would be appreciated.

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Strange 404 error in admin

[Julien Phalip]

Hi,

This is a strange case. I have a simple blog entry model which can be
edited in the admin, from the URL that looks like:
http://www.example.com.au/admin/blog/entry/52/

Now, what is strange is that the link above returns a 404. Same with
the entry id=51. Yet, entries with id=51,52 do exist.

- All other entries (with id < 51) work fine in the admin.
- All entries (including id=51,52) work fine on the front end.
- Everything works fine when I test it locally on my computer with a
replica of the online database.

I've never come across something like that, and I'm not sure where to
look to debug this. Would you have some hints to suggest?

Thanks a lot for your help,

Julien

PS: It is using a quite old version of Django, a trunk revision
between 0.96 and 1.0.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Displaying the names of executed tests

[Julien Phalip]

On Feb 3, 2:47 am, Alex Koshelev  wrote:
> Look at the `--verbosity` test command option

Thanks Alex, I should have thought of that.

Cheers,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Displaying the names of executed tests

[Julien Phalip]

Hi,

I'd find quite useful to have the names of all the tests displayed
after they have been executed. Instead of just having something like
'Ran 3 tests 0.672s', it'd be good to have something like 'Ran 3 tests
0.672s: test_useraccounts, test_trees, test_blah'.

If that's possible to do, could you please point me out as I can't
find it in the doc.

If that's not possible, do you think this is worth opening a ticket?

Thanks a lot,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Seeking design advice on Django implementation

[Julien Phalip]

On Feb 2, 7:40 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Mon, 2009-02-02 at 00:17 -0800, Julien Phalip wrote:
> > Hi,
>
> > I'm a bit stuck with the design of a system and so I was wondering if
> > someone could give some advice.
>
> > The system works as follows. Users can create documents, which are
> > stored in a Django model. To ensure there's no conflict, a document
> > can be modified only by one user at a time.
> > The edition of a document is made via a Flex application that
> > communicates with the server via Ajax.
> > When a user has finished modifying a document, the document is
> > released and another user can modify it. Finally, if a user wants to
> > open a document, but that document is currently being edited by
> > someone else, then the document would be opened in read-only mode,
> > until the lock is eventually released.
>
> > So far, I'm planning to have something like this:
>
> > class Document(models.Model):
> >     content = models.CharField()
> >     current_user = models.ForeignKey(User)
> >     lock_timestamp = models.DateTimeField()
>
> > As I see it, when the document is first opened, it is locked by
> > setting 'current_user' to request.user and 'lock_timestamp' to the
> > current time. Then, the frontend application keeps sending an ajax
> > request every 30 seconds to the remind the server that it is modifying
> > the document. So, the lock's timestamp is refreshed every 30 seconds
> > that the document is being used. When the frontend app is closed, the
> > timestamp is not refreshed any more, so if another user makes the
> > request at least 30 seconds later, the document will be released and
> > locked to him.
>
> > Does that sound viable? Performance-wise, is that a good system? If
> > not, would you have any other approach to suggest?
>
> I would make the lock objects separate from the document with a
> foreign-key from lock -> document. You might well want to change how
> locking is implemented over time and it's entirely unrelated to the
> concept of "document" (it's part of the concept of "document locking").
> So don't prematurely denormalise.
>
> For example, you could then implement read-only locks of some sort if
> somebody wants to reserve the next writing slot for that document (which
> could be similarly expired). Or you could decide to change the locking
> strategy so that the writer has a 15 minute lock on writing, which is
> renewed whenever they hit "save" or until they release the lock (saying
> they're not editing any longer). That's how MoinMoinWiki does it, for
> example (with a slightly different implementation). If you did use that
> implementation strategy (or wanted to change to it later), you won't
> need to futz around with the "document" model/table, just the lock
> table.
>
> Regards,
> Malcolm

Thanks a lot Malcolm for the tips. Keeping the lock in its own model
separate from the document's model definitely seems like the way to
go.
Also, do you think I should be careful with transactions at the view
level to prevent concurrent requests?

Cheers,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Seeking design advice on Django implementation

[Julien Phalip]

Hi,

I'm a bit stuck with the design of a system and so I was wondering if
someone could give some advice.

The system works as follows. Users can create documents, which are
stored in a Django model. To ensure there's no conflict, a document
can be modified only by one user at a time.
The edition of a document is made via a Flex application that
communicates with the server via Ajax.
When a user has finished modifying a document, the document is
released and another user can modify it. Finally, if a user wants to
open a document, but that document is currently being edited by
someone else, then the document would be opened in read-only mode,
until the lock is eventually released.

So far, I'm planning to have something like this:

class Document(models.Model):
content = models.CharField()
current_user = models.ForeignKey(User)
lock_timestamp = models.DateTimeField()

As I see it, when the document is first opened, it is locked by
setting 'current_user' to request.user and 'lock_timestamp' to the
current time. Then, the frontend application keeps sending an ajax
request every 30 seconds to the remind the server that it is modifying
the document. So, the lock's timestamp is refreshed every 30 seconds
that the document is being used. When the frontend app is closed, the
timestamp is not refreshed any more, so if another user makes the
request at least 30 seconds later, the document will be released and
locked to him.

Does that sound viable? Performance-wise, is that a good system? If
not, would you have any other approach to suggest?

Thanks a lot for your help.

Regards,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Testing uploads and content types

[Julien Phalip]

On Jan 24, 12:57 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Fri, 2009-01-23 at 12:15 -0800, Julien Phalip wrote:
> > On Jan 24, 2:45 am, varikin <vari...@gmail.com> wrote:
> > > The UploadedFile[1] object has a field called content_type. So if you
> > > have this in a form:
>
> > > myfile = request.FILES['some_file']
> > > if myfile.content_type != 'application/zip':
> > >      #raise error
>
> > > I don't know if this will help you in your test. I hope it does.
>
> > > [1]http://docs.djangoproject.com/en/dev/topics/http/file-uploads/#upload...
>
> > > John
>
> > Hi John,
>
> > Thanks for your reply. The snippet you've given is the kind of things
> > my view already does. The problem is that, when testing with
> > self.client.post(), all files are systematically encoded as
> > 'application/octet-stream'. To test the behaviour of my view I need to
> > control the content type of each uploaded files. And it doesn't seem
> > like there's another way than creating a custom request from scratch
> > to achieve that. Is that correct?
>
> That sounds quite believable. After all, you are simulating what a
> browser (or other HTTP client) has to do, which includes setting the
> content type. You'll probably want to write a utility function for
> creating your requests to make your code shorter, but it seems
> reasonable that this is something you have construct. Asking Django's
> test framework to do MIME-type detection by default would take time and
> remove an element of predictability (and even correctness) from the
> tests.
>
> If you come up with a neat, unobtrusive helper function, you might want
> to consider creating a patch for Django's test module.

Just for the record, I created a ticket with patch here:
http://code.djangoproject.com/ticket/10115

Regards,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Testing uploads and content types

[Julien Phalip]

On Jan 24, 2:45 am, varikin  wrote:
> The UploadedFile[1] object has a field called content_type. So if you
> have this in a form:
>
> myfile = request.FILES['some_file']
> if myfile.content_type != 'application/zip':
>      #raise error
>
> I don't know if this will help you in your test. I hope it does.
>
> [1]http://docs.djangoproject.com/en/dev/topics/http/file-uploads/#upload...
>
> John

Hi John,

Thanks for your reply. The snippet you've given is the kind of things
my view already does. The problem is that, when testing with
self.client.post(), all files are systematically encoded as
'application/octet-stream'. To test the behaviour of my view I need to
control the content type of each uploaded files. And it doesn't seem
like there's another way than creating a custom request from scratch
to achieve that. Is that correct?

Thanks,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Testing uploads and content types

[Julien Phalip]

Hi,

I have a view which processes a multi-part form and whose behaviour
varies depending on the content types of the uploaded files. I've
written some tests for that view as follows:

post_data = {
'name1': 'blah',
'file_field1': image_data,
}
response = self.client.post('/upload/', post_data)

But the problem is that (apparently by design) all files are
systematically encoded with the content type 'application/octet-
stream'.

I have found a way around that, but only by writing a very long piece
of code to create a customised request from scratch:

payload = []
payload.extend([
'--' + client.BOUNDARY,
'Content-Disposition: form-data; name="name1"',
'',
'blah'
])
payload.extend([
'--' + client.BOUNDARY,
'Content-Disposition: form-data; name="file_field1";
filename="image1.png"',
'Content-Type: image/png',
'',
image_data
])
payload.extend([
'--' + client.BOUNDARY + '--',
'',
])
payload = "\r\n".join(payload)

r = {
'CONTENT_LENGTH': len(payload),
'CONTENT_TYPE':   client.MULTIPART_CONTENT,
'PATH_INFO':  "/upload/",
'REQUEST_METHOD': 'POST',
'wsgi.input': client.FakePayload(payload),
}
response = self.client.request(**r)

Is there a more concise or more elegant way to do?

Thanks a lot for your help,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

'extra' modifier and generic relations

[Julien Phalip]

Hi,

I have an Event model which can have comments. Comments can be added
to any kind of objects so the Comment model uses a generic relation
via content types.

When displaying a list of events I would like to display the number of
comments for each event. To improve performance and limit the number
of queries I'd like to use the 'extra' queryset modifier, but is that
even possible? The fact that it uses a generic relation means that I
need to know the content type id. If I hardcode that id in the 'extra'
statement then the site cannot reliably be ported to another database.

Can the extra modifier be reliably used with generic relations, or is
there a workaround?

Thanks a lot for your advice.

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Strange timeout issue

[Julien Phalip]

Hi,

I have a pretty big database of organisations, countries and news
entries. It all works fine except when I edit one of the organisations
in the admin. The edit page loads fine, but when I click 'Save' it
takes for ever before eventually timing out. The error my clients get
on their system (IE7) is as follows:

*  Error Code 1460: Timeout
* Background: The gateway could not receive a timely response from
the website you are trying to access, a DNS server, or another gateway
server. This might indicate that the network is congested or that the
website is experiencing technical difficulties.
* Date: 5/12/2008 0:12:36 AM
* Source: Firewall

It works when editing any other organisation. I can't find anything
suspicious in the data. It's pretty simple stuff, like address, phone
number, etc.

I'm not sure where to start to debug this. Would you have any
suggestion?

Thanks a lot,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Preventing spam attacks on Ajax views

[Julien Phalip]

On Nov 29, 10:32 pm, Andrei Eftimie <[EMAIL PROTECTED]> wrote:
> Probably best thing would be to have accounts...
>
> On Nov 29, 12:27 am, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > I'm building a rating app, so people can rate any kind of object (e.g.
> > a video, a news entry, etc.). The rating is done anonymously (there's
> > no user account on that site) and via an Ajax query. The view
> > currently only takes one parameter, the rating value (a float), so I
> > don't think I can use something like Akismet.
>
> > To prevent multiple ratings by the same person, a flag is set in the
> > session. Obviously it means that the person can rate again if she uses
> > a different browser or if the session expires, but that's not a big
> > issue.
>
> > Now, what worries me is potential spam attacks. How can I identify if
> > the request is from a genuine person or a bot? I started implementing
> > a system which records IP addresses and prevents anybody to rate twice
> > from the same IP within a given short time. But if genuine persons are
> > behind a proxy, IP uniqueness cannot be guaranteed and they may be all
> > mistaken for a bot.
>
> > Are there some algorithms in Django to cope with this kind of
> > situations? Maybe passing some kind of key protection in the URL?
>
> > Thanks a lot,
>
> > Julien

Thanks for your replies Andrei and Malcolm. Unfortunately that site
does not (and will not) have user accounts, and the client does not
want captcha-like solutions either ("too cumbersome for users"). So I
guess there is no perfect protection here, but in this case we'll
resort to monitoring IPs and time between requests to do a first layer
of protection. That should be enough for the size and popularity of
that site.

Regards,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Preventing spam attacks on Ajax views

[Julien Phalip]

Hi,

I'm building a rating app, so people can rate any kind of object (e.g.
a video, a news entry, etc.). The rating is done anonymously (there's
no user account on that site) and via an Ajax query. The view
currently only takes one parameter, the rating value (a float), so I
don't think I can use something like Akismet.

To prevent multiple ratings by the same person, a flag is set in the
session. Obviously it means that the person can rate again if she uses
a different browser or if the session expires, but that's not a big
issue.

Now, what worries me is potential spam attacks. How can I identify if
the request is from a genuine person or a bot? I started implementing
a system which records IP addresses and prevents anybody to rate twice
from the same IP within a given short time. But if genuine persons are
behind a proxy, IP uniqueness cannot be guaranteed and they may be all
mistaken for a bot.

Are there some algorithms in Django to cope with this kind of
situations? Maybe passing some kind of key protection in the URL?

Thanks a lot,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Testing dynamic apps

[Julien Phalip]

On Nov 28, 1:21 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Thu, Nov 27, 2008 at 11:21 AM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > I'm keen to try to find some proper ways to fix this, but before I go
> > too deep into the bowels of Django's testing framework, I was
> > wondering what would be the criticisms you'd have about the "solution"
> > I came up with (at the start of this thread)? It sort of works without
> > patching Django, but is it acceptable? and if not, why?
>
> > At this stage, it looks good enough to me except for two main points
> > that feel dirty:
> > 1) the test models should be unloaded after the test is run
> > 2) potential conflicts with external apps should be avoided.
>
> I will openly admit that I haven't given this much though, except in
> the abstract. I'm certain that there are many details and gotchas that
> I haven't thought of that implementation will reveal.
>
> Broadly speaking, I'm happy with the approach you are suggesting. The
> interface needs some work, though. I'd like to think that at an API
> level, it could be as simple as:
>
> class MyMetaTest(TestCase):
>     apps = ['fakeapp','otherapp']
>
>     def test_stuff(self):
>       ...
>
> where 'fakeapp' et al are submodules of the test module that contain a
> models.py definition. Obviously, the test applications need to be:
>  - Added to INSTALLED APPS and the app cache on startup
>  - Installed in the app cache before the syncdb caused by the pre-test
> database flush takes effect. You shouldn't need to manually invoke
> syncdb.
>  - Removed from INSTALLED_APPS and the app cache on teardown
>
> I'm of two minds as to whether apps should define a complete
> replacement for INSTALLED_APPS, or if it should be a supplement to the
> INSTALLED_APPS that already exists for the project. This hits up
> against the recurring issue of testing as a per-app process vs testing
> as a project integration process.
>
> The name clash problem you describe shouldn't be that big an issue -
> you have the django-admin model validation tools at your disposal. You
> will probably want to put in some checks to make sure that validation
> only gets called once (so that you're not needlessly revalidating),
> but the validator should pick out any name clashes or other conflicts.
>
> Russ %-)

Thanks a lot for the feedback and pointers. I'll think about it over
the next few days and will try to post a first sketch patch in the
ticket.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Clearing test client's session

[Julien Phalip]

On Nov 27, 7:17 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm writing some tests for a view that sets entries in the session.
> Everything works fine, the entries are properly set and the session
> seems to work ok (using the default DB SessionStore).
>
> However, I can't seem to find how to clear the session. I've tried the
> following, which doesn't work:
>
> self.client.post('/blah/1/') #Sets an entry in the session
> self.client.session.clear()
> #The session's entry still exists
>
> What is the proper way to do this?
>
> Thanks a lot,
>
> Julien

Never mind. I've used self.client.session.flush() instead and it
worked fine.

Cheers,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Clearing test client's session

[Julien Phalip]

Hi,

I'm writing some tests for a view that sets entries in the session.
Everything works fine, the entries are properly set and the session
seems to work ok (using the default DB SessionStore).

However, I can't seem to find how to clear the session. I've tried the
following, which doesn't work:

self.client.post('/blah/1/') #Sets an entry in the session
self.client.session.clear()
#The session's entry still exists

What is the proper way to do this?

Thanks a lot,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Testing dynamic apps

[Julien Phalip]

I'm keen to try to find some proper ways to fix this, but before I go
too deep into the bowels of Django's testing framework, I was
wondering what would be the criticisms you'd have about the "solution"
I came up with (at the start of this thread)? It sort of works without
patching Django, but is it acceptable? and if not, why?

At this stage, it looks good enough to me except for two main points
that feel dirty:
1) the test models should be unloaded after the test is run
2) potential conflicts with external apps should be avoided.

Any advice/hint welcome ;)

Julien

On Nov 27, 12:42 pm, Rock <[EMAIL PROTECTED]> wrote:
> I took a similar path. I cloned the run_tests function from
> django.tests.simple.py and put it in my project directory as
> test_setup.py while adding this near the top of the function:
>
> if settings.TEST_APPS:
>     settings.INSTALLED_APPS += settings.TEST_APPS
>
> That at least allows me to define TEST_APPS in my main settings file
> for the project and in a location near INSTALLED_APPS so that I am
> less likely to introduce unintended collisions. But my approach feels
> dirty too. It shouldn't take much work to incorporate a TEST_APPS
> construct into the existing test framework. I realize it might be
> nicer if each batch of unit tests could define their own set of extra
> test models, but I think that a master list of additional test apps
> like above has the advantage of simplicity. But I haven't given this a
> lot of thought beyond this simple minded hack.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Testing dynamic apps

[Julien Phalip]

On Nov 27, 10:55 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Thu, Nov 27, 2008 at 8:33 AM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > So, all this works pretty well. The 'fakeapp' app is loaded
> > dynamically, tables are created and the FakeItem model can be use in
> > my tests.
>
> > But it feels dirty. The dynamically created tables can potentially
> > clash with some other applications (what if someone calls their app
> > 'fakeapp'?). To make it safer maybe I could give a random name to that
> > app (e.g. 'uytwe876435gjhgdfs0908').
>
> > Is there a cleaner way to do this? In a similar app (django-voting
> > [1]) there is a dedicated test suite, but I'd like to avoid that if
> > possible.
>
> You aren't the first person to have this need: this is logged as
> ticket #7835. The problem exists for any project that works at the
> meta level, working on models rather than with models. For example
> contrib.admin needs test models in order to validate that the admin
> can display different types of models correctly.
>
> contrib.admin works around the problem by putting the tests in the
> Django system test suite, rather than in the contrib app itself. Based
> on your description, this sounds like the same approach Django-voting
> has used. This approach works fine if you're willing to maintain an
> external test suite, but doesn't provide an integrated test suite that
> can be easily distributed with your app.
>
> This is one of those problems that I want to solve, but I haven't yet
> given a great deal of though into how to solve. I've got a few vague
> ideas banging around in my head about allowing test application and
> test model definitions to be included in the test module for an
> application, but those ideas aren't fully formed. Anyone that wants to
> help out with some concrete suggestions (and even better - code) is
> more than welcome to do so.
>
> Yours,
> Russ Magee %-)

Thank you Russell for pointing me to this ticket. I'm quite keen to
find a solution for this, so I will give it some thought and maybe
give a shot at writing some code.

Cheers,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Testing dynamic apps

[Julien Phalip]

Hi,

I have an app which allows users to rate/vote for any kind of object.
Now, to test this app I need to have a fake model contained in a fake
app. Here's the file structure of my app:

myapp/
tests/
fakeapp/
__init__.py
models.py
__init__.py
models.py
views.py
urls.py

Here is the testing code (located in myapp/tests/__init__.py):

import sys

from django.test import TestCase
from django.conf import settings
from django.core.management import call_command
from django.db.models.loading import load_app

from fakeapp.models import FakeItem

class TestMyApp(TestCase):

def setUp(self):
self.old_INSTALLED_APPS = settings.INSTALLED_APPS
settings.INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'myapp',
'myapp.tests.fakeapp',
)
load_app('myapp.tests.fakeapp')
call_command('syncdb', verbosity=0, interactive=False) #
Create tables for fakeapp

def tearDown(self):
settings.INSTALLED_APPS = self.old_INSTALLED_APPS

def test_blah(self):
item = FakeItem.objects.create(name="blah")
#Do some testing here...

So, all this works pretty well. The 'fakeapp' app is loaded
dynamically, tables are created and the FakeItem model can be use in
my tests.

But it feels dirty. The dynamically created tables can potentially
clash with some other applications (what if someone calls their app
'fakeapp'?). To make it safer maybe I could give a random name to that
app (e.g. 'uytwe876435gjhgdfs0908').

Is there a cleaner way to do this? In a similar app (django-voting
[1]) there is a dedicated test suite, but I'd like to avoid that if
possible.

Thanks a lot for your advice.

Regards,

Julien

[1] http://code.google.com/p/django-voting/source/browse/#svn/trunk/voting/tests

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Testing dynamic templates

[Julien Phalip]

On Nov 25, 11:18 pm, Tim Chase <[EMAIL PROTECTED]> wrote:
> > Check out django.contrib.auth.tests.views.py.
>
> Is there some master index of documentation for "if you want to
> test X, see Y.py or http://Z for an example of how to do it"?
> where X is any of a number of Django features such as models,
> views, templates, middleware, filters, template-tags, forms,
> database-configurations, custom field-types, etc?
>
> I've read through
>
> http://docs.djangoproject.com/en/dev/topics/testing/?from=olddocs
>
> and there are some good specifics here (I'd expect that several
> of the "see http://Z; links would point here).  However, it would
> be nice to have a "testing cookbook" that would attack the topic
> by "thing you want to test" (perhaps with both unittest and
> doctest examples).
>
> Most of my learning-to-test-my-Django-app has happened through
> trial and error, so any sort of "you want to test X, see Y" would
> be helpful.
>
> -tim

Russ, thanks again for the tip (combination of setUp trickery and
custom template loader). That would in fact be even better because it
means you don't rely on "os" and on the file system, which is good if
you're dealing with AppEngine I suppose.

Tim, I couldn't agree more. There is a big lack of practical examples
in the documentation. Most of what I learned was from django's test
suite itself or from popular third party apps. Eric Holscher recently
started a discussion on his blog [1] about this, and I tried to reply
to it in my blog [2]. Let's keep the discussion going (I mean, not
necessarily in this thread, but on blogs and forums maybe)!
It'd be great to improve the doc. It would open the doors of testing
to the community and everyone would eventually benefit from it!

Russ and Malcolm (if you're still here :) ), I'd love to hear your
view on this, as I know testing is very important in your eyes.

Regards,

Julien

[1] http://ericholscher.com/blog/2008/nov/13/stubbing-out-tests-django/
[2] 
http://www.julienphalip.com/blog/2008/11/15/misconceptions-about-testing-and-what-we-should-do/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Testing dynamic templates

[Julien Phalip]

On Nov 25, 10:56 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Tue, 2008-11-25 at 20:47 +0900, Russell Keith-Magee wrote:
> > On Tue, Nov 25, 2008 at 8:40 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > > Hi,
>
> > > I've got a view which uses a different template depending on an input
> > > parameter. For example:
>
> > > def my_view(request, theme):
> > >    ...
> > >    return render_to_response('my_app/%s/page.html' %s theme, {...})
>
> > > I would like to write some tests for this view, but I couldn't find
> > > any clean way to do so. So far, the only way I've found was to create
> > > a fake folder in the app's templates:
>
> > > my_app/
> > >    templates/
> > >        my_app/
> > >            test_blah/
> > >                page.html
> > >    models.py
> > >    tests.py
> > >    views.py
>
> > > And then I can test the view by sending it the parameter 'test_blah'.
> > > It works fine, but it means I have to ship my app with that dirty
> > > "test_blah" folder.
>
> > > Is there any other way to proceed?
>
> > Check out django.contrib.auth.tests.views.py. The ChangePasswordTest
> > does some fancy footwork during the setUp and tearDown to install some
> > templates for testing purposes. You still need to ship the templates
> > as part of your project tarball, but they don't need to be in a
> > production-visible location - you can hide them away as part of the
> > testing infrastructure.
>
> Another approach is to write a custom template loader that is used in
> your test settings file. There's nothing to say a template loader has to
> actually load a file. It has to return a template, given the name. You
> can do that however you like.
>
> Regards,
> Malcolm

Thanks also for this tip, Malcolm. Both approaches are quite elegant.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Testing dynamic templates

[Julien Phalip]

On Nov 25, 11:01 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> On Nov 25, 10:56 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > On Tue, 2008-11-25 at 20:47 +0900, Russell Keith-Magee wrote:
> > > On Tue, Nov 25, 2008 at 8:40 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > > > Hi,
>
> > > > I've got a view which uses a different template depending on an input
> > > > parameter. For example:
>
> > > > def my_view(request, theme):
> > > >    ...
> > > >    return render_to_response('my_app/%s/page.html' %s theme, {...})
>
> > > > I would like to write some tests for this view, but I couldn't find
> > > > any clean way to do so. So far, the only way I've found was to create
> > > > a fake folder in the app's templates:
>
> > > > my_app/
> > > >    templates/
> > > >        my_app/
> > > >            test_blah/
> > > >                page.html
> > > >    models.py
> > > >    tests.py
> > > >    views.py
>
> > > > And then I can test the view by sending it the parameter 'test_blah'.
> > > > It works fine, but it means I have to ship my app with that dirty
> > > > "test_blah" folder.
>
> > > > Is there any other way to proceed?
>
> > > Check out django.contrib.auth.tests.views.py. The ChangePasswordTest
> > > does some fancy footwork during the setUp and tearDown to install some
> > > templates for testing purposes. You still need to ship the templates
> > > as part of your project tarball, but they don't need to be in a
> > > production-visible location - you can hide them away as part of the
> > > testing infrastructure.
>
> > Another approach is to write a custom template loader that is used in
> > your test settings file. There's nothing to say a template loader has to
> > actually load a file. It has to return a template, given the name. You
> > can do that however you like.
>
> > Regards,
> > Malcolm
>
> Thanks also for this tip, Malcolm. Both approaches are quite elegant.

I should add that the trickery used in ChangePasswordTest might be
slightly better because it means the tests are self-contained, and so
they don't depend on external parameters (e.g. the tests settings).
The big advantage I see is that it makes the app more portable, at
least as far as tests are concerned. Just tried it and it works like a
charm!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Testing dynamic templates

[Julien Phalip]

Excellent! Thanks for the tip Russ ;)

On Nov 25, 10:47 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Tue, Nov 25, 2008 at 8:40 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > I've got a view which uses a different template depending on an input
> > parameter. For example:
>
> > def my_view(request, theme):
> >    ...
> >    return render_to_response('my_app/%s/page.html' %s theme, {...})
>
> > I would like to write some tests for this view, but I couldn't find
> > any clean way to do so. So far, the only way I've found was to create
> > a fake folder in the app's templates:
>
> > my_app/
> >    templates/
> >        my_app/
> >            test_blah/
> >                page.html
> >    models.py
> >    tests.py
> >    views.py
>
> > And then I can test the view by sending it the parameter 'test_blah'.
> > It works fine, but it means I have to ship my app with that dirty
> > "test_blah" folder.
>
> > Is there any other way to proceed?
>
> Check out django.contrib.auth.tests.views.py. The ChangePasswordTest
> does some fancy footwork during the setUp and tearDown to install some
> templates for testing purposes. You still need to ship the templates
> as part of your project tarball, but they don't need to be in a
> production-visible location - you can hide them away as part of the
> testing infrastructure.
>
> Yours,
> Russ Magee %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Testing dynamic templates

[Julien Phalip]

Hi,

I've got a view which uses a different template depending on an input
parameter. For example:

def my_view(request, theme):
...
return render_to_response('my_app/%s/page.html' %s theme, {...})

I would like to write some tests for this view, but I couldn't find
any clean way to do so. So far, the only way I've found was to create
a fake folder in the app's templates:

my_app/
templates/
my_app/
test_blah/
page.html
models.py
tests.py
views.py

And then I can test the view by sending it the parameter 'test_blah'.
It works fine, but it means I have to ship my app with that dirty
"test_blah" folder.

Is there any other way to proceed?

Thanks a lot,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Valid URL rejected by URLField

[Julien Phalip]

Hi,

The following URL is rejected when validating a URLField form field:
http://portal.oas.org/Portal/Topic/SEDI/Educaci%C3%B3nyCultura/Cultura/ReunionesdelosMinistrosdeCultura/Cuartareuni%C3%B3nministerial/tabid/1416/language/en-US/language/es-CO/Default.aspx

Yet, that URL works perfectly in a browser. The error I get is:
"HTTP Error 302: The HTTP server returned a redirect error that would
lead to an infinite loop.
The last 30x error message was:
Found"

Is there a way around that, other than by switching "verify_exists"
off?

Thanks a lot,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Clash between file upload handler and middleware accessing request's dictionaries

[Julien Phalip]

Hi,

Upload handlers cannot be set after the request's POST or FILES
dictionaries have been accessed. The problem I'm having is that one of
the middleware I use (packaged with the django-pagination app)
actually accesses request.REQUEST when the request comes in.

Therefore it is impossible to set the upload handler dynamically at
the beginning of the view.

Is there a way around that? Also, is that bad practice to access those
dictionaries from within a middleware?

Thanks for your advice,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Template.render and custom tags

[Julien Phalip]

You might want to give a shot with 'add_to_builtins':
http://blog.michaeltrier.com/2007/8/7/common-template-tags

On Sep 13, 11:05 am, akonsu <[EMAIL PROTECTED]> wrote:
> hello,
>
> is there a way to make my custom tags and filters available to a
> template that i create from a string like this:
>
> template = Template(string)
> template.render(context)
>
> i know that i can use the "load" tag in the template, but suppose that
> the strings that i create templates from do not have the load tag and
> i have no way to change that. i can of course do
>
> template = Template('{% load mytags %}' + string)
>
> but is there a better way?
>
> thanks
> konstantin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Ongoing UnicodeDecodeError's with web crawlers and file caching

[Julien Phalip]

Hi,

I'm running a fairly large website (10,000 news items). Initially it
was made in ASP with MSSQL, then I took the project over and ported it
to PHP and MYSQL. Finally, 6 months ago I ported it to Django and
MySQL.

Now, ever since the site has been running on Django, I've received
about a dozen error emails every couple of days (once I even received
400 overnight!). Those errors are systematically caused by web
crawlers (yahoo slurp, googlebot, msn, yeti, etc.). It systematically
chokes on the same line of code, which is loading some data from file
caching. The traceback is pretty much always as follows:

 File "/MYPATH/apps/news/templatetags/news_tags.py", line 13, in
show_sidebar
   cached_sidebar = cache.get('the_sidebar')

 File "/MYPATH/django/core/cache/backends/filebased.py", line 50, in
get
   return pickle.load(f)

UnicodeDecodeError: 'utf8' codec can't decode byte 0x8a in position
5999: unexpected code byte

The actual utf-8 character varies each time.

I spent a lot of time cleaning up, reorganising and improving the
code... in vain. Now I strongly suspect it might be because of the
data being corrupted in some way.

Now, what puzzles me is that all the URLs which fail with web
crawlers, actually work perfectly well when I simply open them in a
browser.

The code has always followed a recent trunk of Django and now runs on
1.0. I have already raised that issue in this mailing list a couple of
times in the past, but I didn't get much help. I haven't opened a
ticket because I cannot reproduce the error myself (it only happens
with web crawlers) and because I suspect it might be because of my
setup (no other site that I have and use file caching have this
problem).

I could also say that the site was originally running with mod_python,
then with mod_wsgi, and has even moved servers. After all these
changes the problem is still there, to it seems to be independent from
server configuration.

So, any hint to debug this would be very much appreciated. If you
think this is worth filing a ticket, I'd also appreciate any hint on
how to phrase this problem correctly.

Thanks a lot for your help.

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Weird ImproperlyConfigured error

[Julien Phalip]

> I've spent a couple hours trying to debug this, in vain...

I figured out my problem, so I just thought I'd post it here.

It was in fact due to some stale .pyc files and folders, not in my
apps but in Django itself. I had just done an 'svn update' on it, and
apparently some old stuff kept hanging around. So my best advice to
anybody would be to start from a clean check out when 1.0 storms out.
That'll make you avoid some frustration like I've just been through ;)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Changing the AuthenticationForm username's max_length field (impossible!?)

[Julien Phalip]

As an alternative, you can also check the patch in ticket #8274
http://code.djangoproject.com/ticket/8274

It has been pushed post-1.0, but in the meantime it could be of some
help for you. It gives full control on the form to use in the login
view, and so allows you not to monkey-patch the code dynamically.

Cheers,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Changing the AuthenticationForm username's max_length field (impossible!?)

[Julien Phalip]

Keltus,

The patch I mentioned in that thread solved the problem of validating
the input. For the rendering of the form, you also need to patch the
widget as follows:

AuthenticationForm.base_fields['username'].widget.attrs['maxlength'] =
75

Note that here 'maxlength' doesn't take an underscore.

Regards,

Julien

On Aug 30, 4:04 pm, keltus <[EMAIL PROTECTED]> wrote:
> After many frustrating hours, I have yet to monkey patch the
> form.username variable from:
> 
> to
> 
>
> In my urls.py file, I added:
> from django.contrib.auth.forms import AuthenticationForm
> AuthenticationForm.base_fields['username'].max_length = 75
> AuthenticationForm.base_fields['username'].label = "Email"
>
> This is suggested by Julien in his 
> post:http://groups.google.com/group/django-developers/msg/3420dc565df39fb1
>
> I found that {{ form.username.label_tag }} will print "Email" as
> expected, but {{ form.username }} still prints a max_length of 30.
>
> I tested using:
> assert False, dir(AuthenticationForm.base_fields['username'])
> and indeed the max_length field is 75 (and before my code, it's 30 as
> expected)
>
> Why won't the maxlength html field change to 75? This perplexes me.
>
> This is using django 1.0 beta 1, but I've also tried with django 1.0
> beta 2 and django svn trunk.
>
> Please advise.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Weird ImproperlyConfigured error

[Julien Phalip]

Hi,

I've spent a couple hours trying to debug this, in vain...

I'm setting up a very simple site. In that site I've copied/pasted the
flatpages app to be able to extend it at will (I call the new app
'staticpages').

Everything works fine on the local machine running with the dev
server. But when I run the site on the production server with Apache,
nothing works at all and I get:

mod_wsgi (pid=12338): Exception occurred processing WSGI script '/
MYPATH/myproject.wsgi'.
Traceback (most recent call last):
  File "/MYPATH/django/core/handlers/wsgi.py", line 194, in __call__
self.load_middleware()
  File "/MYPATH/django/core/handlers/base.py", line 40, in
load_middleware
raise exceptions.ImproperlyConfigured, 'Error importing middleware
%s: "%s"' % (mw_module, e)
  ImproperlyConfigured: Error importing middleware
staticpages.middleware: "No module named widgets"

Only removing that middleware from the MIDDLEWARE_CLASSES setting gets
rid of the error.

I thought it was due to some stale *.pyc files, but I started from a
clean checkout and the problem persists.

I really don't understand where it's trying to import that 'widgets'
module. Certainly not from the middleware module, which is the same as
the flatpage's one:
http://code.djangoproject.com/browser/django/trunk/django/contrib/flatpages/middleware.py

The traceback is really not helpful. Would you have any hint to debug
this?

Thanks a lot!

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: File upload and access properties

[Julien Phalip]

> That is the subject of ticket #8454.

Thanks Malcolm! I had missed that one. I like the proposed patch.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

File upload and access properties

[Julien Phalip]

Hi,

I'm using the FileSystem storage to save uploaded files, in a very
basic way:

storage.save('/blah/test.mp3', uploaded_file)

Now, the resulting file has '600' file access properties. That file is
then served by apache, but because of those access properties, it
cannot be accessed as you get a '403 Forbidden' error.

Is there a way to force the properties for the stored file (e.g. 605
would be enough)?

Thanks!

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Noob: form class location

[Julien Phalip]

The import is likely to be in your view:

# views.py
from forms import MyForm

myview(request):
if request.method == 'POST':
form = MyForm(request.POST)
...

That's assuming that views.py and forms.py are at the same level.

Cheers,

Julien

On Aug 23, 11:25 pm, Gerard Petersen <[EMAIL PROTECTED]> wrote:
> Julien/Russell,
>
> Thanx for the info. Working around the name class would simply be resolved by 
> a 'myforms.py' (or something). One thing is still missing in my brain though. 
> If I put it in a myforms.py. How does Django (or my code if you will) knows 
> where to find this class. There should be an import statement somewhere then, 
> right?
>
> Forgive my Django noobness. And thanx a lot!!
>
> Regards,
>
> Gerard.
>
>
>
> Russell Keith-Magee wrote:
> > On Sat, Aug 23, 2008 at 8:59 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
> >> Hi,
>
> >> In Django there are no 'standard' as such. You'd talk more about
> >> 'conventions'.
> >> One common way is to put all your forms in forms.py. But that's just
> >> for cleanliness.
>
> > While this is a common convention, I would point out that it is not
> > without problems. If you have a local 'forms.py' module, you leave
> > yourself open to name clashes if you use 'from django import forms' in
> > your code.
>
> > However, the rest of your advice is correct - there is not set rule,
> > just conventions, and as long as Python can import it, the code will
> > work the same regardless of the location.
>
> > Yours,
> > Russ Magee %-)
>
> --
> urls = { 'fun':  'www.zonderbroodje.nl',  'tech':  'www.gp-net.nl'}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Noob: form class location

[Julien Phalip]

Hi,

In Django there are no 'standard' as such. You'd talk more about
'conventions'.
One common way is to put all your forms in forms.py. But that's just
for cleanliness. Python lets you create whatever architecture you like
for your apps. So, basically, do whatever you feel most comfortable
with ;)
Personally, for each app, I usually separate the classes and functions
in the following modules: models, admin, views, forms, urls, utils
(for the helper functions).

Cheers,

Julien

On Aug 23, 10:29 pm, Gerard Petersen <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> Im working on forms, going through this 
> book:http://www.djangobook.com/en/1.0/chapter07/
>
> I need to place a form class like this somewhere:
>
> class ContactForm(forms.Form):
>     topic = forms.ChoiceField(choices=TOPIC_CHOICES)
>     message = forms.CharField(widget=forms.Textarea())
>     sender = forms.EmailField(required=False)
>
> I'm torn between models.py and views.py. And I read about a forms.py, but 
> that is not a 'standard' framework file.
>
> So, where do I put this?
>
> Thanx all!
>
> Regards,
>
> Gerard.
>
> --
> urls = { 'fun':  'www.zonderbroodje.nl',  'tech':  'www.gp-net.nl'}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Upload image in own form

[Julien Phalip]

Hi,

I think that you need to set the form's object instance when
collecting the POST data too:

form = WrestlerProfileForm(request.POST, request.FILES,
instance=profile)

That way, the image will be set with the existing one, and the form
won't complain when validating.

Hope it helps,

Julien

On Aug 21, 4:09 pm, Robvdl <[EMAIL PROTECTED]> wrote:
> I've got a model with an ImageField in it:
>
> image = models.ImageField(upload_to='images/wrestlers',
> help_text='...')
>
> I can upload images no problem using the Admin app.
>
> I wish to upload images in my own Django app, so I created a form:
>
> class WrestlerProfileForm(forms.ModelForm):
>     class Meta:
>         model = WrestlerProfile
>         exclude = ('user',)
>
> Now say I already saved a wrestler profile in admin and uploaded a
> picture. In admin, if I re-edit that same profile, the image field is
> still set (i.e. contains an image), and I can leave it as is, just
> edit the other fields and leave the image field alone, it saves no
> problem.
>
> If I do this in my app, it won't populate the image field when the
> form is first shown, even though I use instance=profile when I
> initialize the form, it only populates the other fields. If I hit
> save, it complains that the image field is required. I am able to save
> if I upload another picture, but this is not what I want to have to
> do, always upload a picture, just to be able to save the profile.
>
> Here is my view:
>
> @login_required
> def edit_profile(request):
>     try:
>         profile =
> WrestlerProfile.objects.get(user__username=request.user.username)
>     except WrestlerProfile.DoesNotExist:
>         profile = None
>     if request.method == 'POST':
>         form = WrestlerProfileForm(request.POST, request.FILES)
>         if form.is_valid():
>             wrestler = form.save(commit=False)
>             wrestler.user = request.user
>             if not profile is None:
>                 wrestler.id = profile.id
>             wrestler.save()
>             return HttpResponseRedirect(request.META['PATH_INFO'])
>     else:
>         if profile == None:
>             form = WrestlerProfileForm()
>         else:
>             form = WrestlerProfileForm(instance=profile)
>     return render_to_response('registration/profile.html', {
>         'form': form,
>     }, context_instance=RequestContext(request))
>
> The reason why I save with commit=False then set the wrestler.id to
> profile.id, is because if you look at my form, you may notice I
> exclude the user field, which I actually get from the current logged
> in user.
>
> However, the problem is before that, it actually complains about the
> missing image field at the time I execute form.is_valid().
>
> Any ideas how to get around this issue?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Renaming of mailing lists to avoid user confusion

[Julien Phalip]

On Aug 21, 4:43 am, "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 19, 2008 at 11:16 AM, Tom Tobin <[EMAIL PROTECTED]> wrote:
> > Let me propose a stopgap: edit the django-users and django-developers
> > pages to state, in large bold text, what the purpose of each list is
> > (this is "edit welcome message" in Google Groups).  Let's see if that
> > helps any, and come back to this in a month or so.
>
> Amidst the concern over split archives, filters, and topics (some of
> which is valid, I'll grant), I was disappointed to see this suggestion
> go unremarked.  This is an *easy* action that might have immediate
> beneficial consequences, has no drawbacks, and will take someone all
> of five minutes to accomplish.

I too think this is by far the best solution.

Most support questions posted in django-dev are posted by new comers.
Once they've been told they posted in the wrong list, they don't post
there again (I mean, they don't post *support questions* there again).

Also, I think that most new comers first access either django-users or
django-dev via the web interface. I don't have any proof of that, but
that's what seems most probable.

So, add that note on the django-dev and django-users group web
interface. It doesn't cost anything and I bet it will prevent 90% (if
not all) of the problematic emails.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Browser timeout on long processes

[Julien Phalip]

> If the view is running a loop -  how would you provide a variable to another
> view (that Ajax is calling) about the situation? Let's say a percentage
> complete -- I immediately think of a global variable, but am not sure how
> this works in a multi-user web situation.

You could use the cache by setting a key that the other view can look
up.

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Browser timeout on long processes

[Julien Phalip]

On Aug 20, 12:15 pm, Graham Dumpleton <[EMAIL PROTECTED]>
wrote:
> That is only half the answer.
>
> Before you get to this point you need a means of backgrounding the
> task to be completed.

You're quite right, I had completely overlooked that side of things ;)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Browser timeout on long processes

[Julien Phalip]

Hi,

You could use Ajax for this. The client could periodically (say, every
second) send a request to the server asking if the calculation is
over. When the calculation is over, a flag would be set (in the
server's cache, for example) and the client would be notified at the
next ajax request.

That should work and be quite simple to implement.

Cheers,

Julien

On Aug 20, 10:37 am, makebelieve <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've built an app that accepts inputs from the user and then uses them
> to do some heavy data crunching.  I've got everything working
> correctly, however, on some runs the process is too long and the
> browser times out before it can complete.  Does anyone know a way
> around this?  Ideally after hitting the calculate button I'd like to
> take the user to a "Calculations in Progress" page until the data
> crunching is complete.  Any ideas on how to accomplish this?
>
> Thank you in advance!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Saving tests' output to a file in Windows

[Julien Phalip]

Hi,

I'm running Django's whole test suite in Windows, from a clean
checkout. I get lots of errors and failures, but there's apparently
some known issues, as described in [1].

Anyway, I can't really debug these errors because the output doesn't
entirely fit in the command window. So I'd like to save the output in
a file, but it doesn't work. I tried:

set PYTHONPATH=E:\django
runtests.py --settings=settings > results.txt

But the file remains empty. I wonder if that's because Django crashes
and the writing is interrupted somehow.

Do you know how I can get it to write the whole output in a text file?

Thanks!

Julien

[1] http://code.djangoproject.com/wiki/DjangoOnWindows
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: propagation of modification in children to parents

[Julien Phalip]

Hi,

The declarative attribute 'auto_now' (as well as 'auto_now_add') is
deprecated and its support will eventually be dropped. To achieve that
you need to override the 'save' method. In that same method you can
also call the parent's 'save' method to propagate the change to the
ancestors:

ModelA(models.Model):
modified = models.DateTimeField()
parent = models.ForeignKey('self', related_name='children',
null=True,
blank=True)

def save(def):
self.modified = datetime.now()
if self.parent:
self.parent.save()
super(ModelA, self).save()

On Jul 20, 6:28 pm, "Andre Meyer" <[EMAIL PROTECTED]> wrote:
> hi all
>
> i have a model with a modifed field
>
> modified = models.DateTimeField(auto_now=True)
>
> and a parent field
>
> parent = models.ForeignKey('self', related_name='children', null=True,
> blank=True)
>
> in order to allow for creating a tree of items.
>
> what is the best way to propagate a modification in a child to set all its
> parents to the same modification time?
>
> or is it possible to sort a query set that retrieves only the top-most items
> (parent=None) on the latest modification time of its children? maybe using a
> method that calculates and returns that date on the fly?
>
> thanks a lot for your help
> André
>
> using trunk 8004, full code is
> here
> .
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Standard documentation method.

[Julien Phalip]

Hi,

Django is just Python, and documentation works the same way as in any
Python code.
Not sure what you're actually after but you might want to check this
excellent article by J. Bennett about documentation:
http://www.b-list.org/weblog/2008/jun/21/documentation/

On Jul 19, 1:52 am, Chris <[EMAIL PROTECTED]> wrote:
> hello,
> Does django have a preferred method of commenting on code in
> docstrings? I notice that there is some specific ways that some
> applications write documentation in their code but didn't know if
> django had some kind of preferred method. I would like to be able to
> parse in my code documentation on the backend using docutils but I
> noticed that I get errors b/c my strings are not formatted a specific
> way.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Using Django Syndication for RSS Feed

[Julien Phalip]

Just found this via google: 
http://lexhair.wordpress.com/2007/08/29/rss-feeds-and-internet-explorer-6/
Apparently IE 6 and RSS are not friends...


On Jul 20, 3:23 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> I'm trying to generate RSS feed for my site using Django's syndication
> framework.
>
> I'm having 2 issues:
>
> 1) While the generated feed gets displayed correctly in Firefox,
> Internet explorer v6x presents a 'save file as' prompt - like it
> doesnt recognize the incoming data as a feed
> Any ideas on how to solve this ?
>
> 2) How can I include an image as part of the generated RSS feed ? do I
> need to use enclosure for it ?
>
> thanks,
> -p.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Sets

[Julien Phalip]

'set' is a Python standard object [1], since version 2.4. In version
2.3 you need to import the 'Set' package first.
So, if you care about backward compatibility in Python, the most
secure way to import it is:

try:
set
except NameError:
from sets import Set as set # Python 2.3 fallback

[1] http://docs.python.org/lib/types-set.html

On Jul 20, 1:23 pm, "Cole Tuininga" <[EMAIL PROTECTED]> wrote:
> Quick question for you folks - is there a native "set" type in the
> Django model system?  I'm currently on 0.96.1.  Thanks!
>
> --
> Cole Tuiningahttp://www.tuininga.org/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Problems with Template "Extends" - Voodoo, anyone?

[Julien Phalip]

Hi,

It is not very clear what problem you're having here. What are those
noticeable differences?

On Jul 19, 12:54 pm, Tye <[EMAIL PROTECTED]> wrote:
> Quick background: I started a new project ("mpi") and app ("main"),
> created a template folder and added its path to settings, and did
> everything I needed to do with database work. Also fooled around with
> Admin (which worked).
>
> What happened: I created an html file from scratch, plopped it into
> the templates dir, hooked it into urls.py, put everything together
> myself, and everything turned out being beautiful and smooth. Then I
> wanted to take advantage of Django's templating mechanisms, starting
> with {% extends "base.html" %} and {% block content %}{% endblock %}.
> I've done it before without issues, so I re-built the "from-scratch"
> html file into two other files we'll just call "base.html" and
> "main.html". I hooked them into a separate url for comparison against
> the original html file.
>
> The browser's "view source" code was *identical* between the two
> versions. The problem? Although the code is _completely identical_,
> somehow there are a few very noticeable differences.
>
> How?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Unicode errors

[Julien Phalip]

Hi,

Could you post the whole traceback? Also, precise what version of
Django you're using. Without that info it's a bit hard to help you.

Cheers,

Julien

On Jul 19, 10:01 pm, Amirouche <[EMAIL PROTECTED]> wrote:
> I got an encoding error while rendering in the admin some text I
> parsed from a feed with feedparser
>
> Caught an exception while rendering: 'ascii' codec can't encode
> character u'\u2605'.
>
> everything is utf-8 compliant (db = sqlite3)  so I don't understand,
> the error happenned in *force_unicode*.
>
> any tips
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Strange ProgrammingError - What causes it?

[Julien Phalip]

Seems like it could be, as you say, related to a problem with psycopg,
see: 
http://groups.google.com/group/comp.lang.python/browse_thread/thread/8e78649ac40472fe/


On Jul 18, 9:14 am, Julien Phalip <[EMAIL PROTECTED]> wrote:
> Which version of Django are you using?
>
> As a first attempt, I'd replace your __str__ method by __unicode__ and
> replace the calls to 'str' by 'unicode'.
>
> On Jul 18, 7:02 am, andrewljohnson <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > I am getting a strange programming error, and I wonder what causes it?
>
> > The Error
> > 
> > ProgrammingError at /trips/viewtrip/2/
> > ERROR: current transaction is aborted, commands ignored until end of
> > transaction block SET client_encoding to 'UNICODE'
>
> > This error is triggered by calling {{trip.owner}}
>
> > If you go to this URL you will see the error in question (I have debug
> > mode turned on):http://www.trailbehind.com/trips/viewtrip/2/
>
> > A Couple of Notes
> > ==
> > 1) This error does not occur if you are logged in as the trip.owner
> > (i.e. trip.owner == request.user).
>
> > 2. This error doesn't occur on my development machine, and I think
> > that may be because I am running a slightly different version of
> > psycopg.
>
> > 3. Here are my relevant models:
>
> > class Trip(models.Model):
> >     """A trip, future or present"""
> >     owner = models.ForeignKey("UserProfile", related_name="owner")
> >     start_date = models.DateField(null = True)
> >     end_date = models.DateField(null = True)
> >     time_created  = models.DateField(auto_now=True)
>
> >     park = models.ForeignKey(Park, blank = True, null = True)
> >     route = models.ManyToManyField(Trail, null = True, blank = True)
>
> >     comments = generic.GenericRelation(Comment, null = True, blank =
> > True)
>
> >     invitee_list = models.ManyToManyField("Invitee")
>
> >     def __str__(self):
> >         return  str(self.id)
>
> >     class Admin:
> >         pass
>
> > class UserProfile(models.Model):
> >     """Extra data about each user."""
>
> >     user = models.ForeignKey(User, unique=True, null=True, blank=True)
> >     summary = models.TextField(null=True)
> >     url = models.URLField(null=True)
> >     home_address = models.TextField(null=True)
> >     phone_number = models.PhoneNumberField(null=True)
> >     email_address = models.EmailField(null=True, unique=True)
> >     user_key = models.CharField(max_length=64, null=True)
>
> >     comments = generic.GenericRelation(Comment)
>
> >     def __str__(self):
> >         if self.user:
> >             return str(self.user)
> >         return str(False)
>
> >     class Admin:
> >         pass
>
> > Thanks for any help!
>
> > Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Strange ProgrammingError - What causes it?

[Julien Phalip]

Which version of Django are you using?

As a first attempt, I'd replace your __str__ method by __unicode__ and
replace the calls to 'str' by 'unicode'.

On Jul 18, 7:02 am, andrewljohnson <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am getting a strange programming error, and I wonder what causes it?
>
> The Error
> 
> ProgrammingError at /trips/viewtrip/2/
> ERROR: current transaction is aborted, commands ignored until end of
> transaction block SET client_encoding to 'UNICODE'
>
> This error is triggered by calling {{trip.owner}}
>
> If you go to this URL you will see the error in question (I have debug
> mode turned on):http://www.trailbehind.com/trips/viewtrip/2/
>
> A Couple of Notes
> ==
> 1) This error does not occur if you are logged in as the trip.owner
> (i.e. trip.owner == request.user).
>
> 2. This error doesn't occur on my development machine, and I think
> that may be because I am running a slightly different version of
> psycopg.
>
> 3. Here are my relevant models:
>
> class Trip(models.Model):
>     """A trip, future or present"""
>     owner = models.ForeignKey("UserProfile", related_name="owner")
>     start_date = models.DateField(null = True)
>     end_date = models.DateField(null = True)
>     time_created  = models.DateField(auto_now=True)
>
>     park = models.ForeignKey(Park, blank = True, null = True)
>     route = models.ManyToManyField(Trail, null = True, blank = True)
>
>     comments = generic.GenericRelation(Comment, null = True, blank =
> True)
>
>     invitee_list = models.ManyToManyField("Invitee")
>
>     def __str__(self):
>         return  str(self.id)
>
>     class Admin:
>         pass
>
> class UserProfile(models.Model):
>     """Extra data about each user."""
>
>     user = models.ForeignKey(User, unique=True, null=True, blank=True)
>     summary = models.TextField(null=True)
>     url = models.URLField(null=True)
>     home_address = models.TextField(null=True)
>     phone_number = models.PhoneNumberField(null=True)
>     email_address = models.EmailField(null=True, unique=True)
>     user_key = models.CharField(max_length=64, null=True)
>
>     comments = generic.GenericRelation(Comment)
>
>     def __str__(self):
>         if self.user:
>             return str(self.user)
>         return str(False)
>
>     class Admin:
>         pass
>
> Thanks for any help!
>
> Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: file upload

[Julien Phalip]

Hi,

Django's upload handling has recently been refurbished and it is now
possible upload large files without upsetting the server. Check the
doc for more info at: 
http://www.djangoproject.com/documentation/upload_handling/

Cheers,

Julien

On Jul 16, 7:49 pm, Niall Mccormack <[EMAIL PROTECTED]>
wrote:
> Hi there,
>
> I've been reading about django file uploads on various blogs. Are  
> there still issues with uploading large files?
>
> I may be creating a site for a production company and will need to  
> ability to upload 5-20mb video files through the cms. Is this just a  
> silly idea? If so, are there any workarounds?
>
> Cheers
> Niall
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Complex queryset construction

[Julien Phalip]

How about:

Item.objects.filter(categories__watching__user=request.user).distinct()

I haven't tested it, but if it works it would return all items watched
by the user. Then, to display items by category, I would use the
regroup tag [1] in the template.

[1] http://www.djangoproject.com/documentation/templates/#regroup

On Jul 16, 6:51 am, Burr Settles <[EMAIL PROTECTED]> wrote:
> Hey fellow djanglers,
>
> I am trying to construct a view that's a bit complicated, and
> struggling to create the proper queryset. Hopefully some of you have
> done something like this before, or otherwise have some ideas on how
> to tackle it efficiently.
>
> Imagine we have something like these models:
>
> class Category(models.Model):
>         name = models.CharField(max_length=100)
>         slug = models.SlugField(unique=True)
>
> class Watching(models.Model):
>         user = models.ForeignKey(User)
>         category = models.ForeignKey(Category)
>         priority = models.IntegerField()
>
> class Item(models.Model):
>         name = models.CharField(max_length=100)
>         description = models.TextField(blank=True)
>         categories = models.ManyToManyField(Category)
>
> What I want to do is create a view at "http://example.com/watchlist/;
> that will show all *items* belonging to all categories which the
> logged-in user is "watching." So, the queryset needs to be a set of
> Item objects, but needs to follow a conditional chain like this: Item -> 
> Category -> Watching -> User -> "ME." This involves a mix of foreign-
>
> key and many-to-many relationships, since users can be watching
> multiple categories, and items can also belong to multiple categories
> (which can, in turn, have multiple items). It should also deal with
> duplicates in case an item belongs to multiple categories that are all
> being watched by the user. (Hopefully that all makes sense!)
>
> Anyway, this particular kind of queryset construction is a little
> unclear to me from the Django DB API documentation.
>
> Any ideas?
>
> --B
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: url (reverse) as a filter

[Julien Phalip]

I guess you would have to preprocess the text with the template
system, reversing all the URLs, and then pass it to markdown
processing.
So, you'd have:

({% url mylink %} "Check this link")


On Jul 16, 3:11 am, gzy <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I like the idea of seperating the.. "address space" of a website from
> the templates. On the other
> hand I'm keeping most of the content in the db and displaying through
> the markup filter.
> So I'm looking for a way to feed the url_bit in markdown's [link]
> (url_bit "Title") to Django's {% url %} tag.
>
> Has anybody done sth similiar? If not, what implementation would you
> suggest?
>
> ...or maybe a markdown extension is the way to go?
>
> grzes
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Logging in with emails longer than 30 characters

[Julien Phalip]

Sorry, I forgot to give the link:

[1] http://www.djangosnippets.org/snippets/74/

On Jul 15, 9:04 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On my site users must login with their email address. I'm successfully
> using a custom authentication backend based on [1].
>
> The problem is with email addresses longer than 30 characters. At the
> moment, these addresses can't log in because the
> django.contrib.auth.forms.AuthenticationForm's username field has a
> maxlength of 30 and therefore validation always fails before even
> hitting the auth backend.
>
> To go around that, I can see 2 options:
> - patch Django and put 75 as the AuthenticationForm username field's
> max_length.
> - create my own login view (duplicating the standard auth login view
> and replacing all the references to AuthenticationForm with my own
> custom form).
>
> None of these 2 options seem to satisfy me completely... What do you
> think is the best practice here?
>
> Thanks a lot,
>
> Julien
>
> PS: I'm using a fresh checkout of newforms-admin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Logging in with emails longer than 30 characters

[Julien Phalip]

Hi,

On my site users must login with their email address. I'm successfully
using a custom authentication backend based on [1].

The problem is with email addresses longer than 30 characters. At the
moment, these addresses can't log in because the
django.contrib.auth.forms.AuthenticationForm's username field has a
maxlength of 30 and therefore validation always fails before even
hitting the auth backend.

To go around that, I can see 2 options:
- patch Django and put 75 as the AuthenticationForm username field's
max_length.
- create my own login view (duplicating the standard auth login view
and replacing all the references to AuthenticationForm with my own
custom form).

None of these 2 options seem to satisfy me completely... What do you
think is the best practice here?

Thanks a lot,

Julien

PS: I'm using a fresh checkout of newforms-admin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: IOError with files uploads bigger than 2.5 MB

[Julien Phalip]

Do you also get a 'No such file or directory' error when using the
FILE_UPLOAD_TEMP_DIR setting, or do you get a different error?

On Jul 14, 5:34 pm, tom <[EMAIL PROTECTED]> wrote:
> hi,
>
> i have done that. I am running the server with the runserver command.
> I tried also different directories using the FILE_UPLOAD_TEMP_DIR
> without any change. This behaviour is reproducable on different
> servers and come up with upgrading to the latest revision of the
> django branch. It has been working before. I increased the
> FILE_UPLOAD_MAX_MEMORY_SIZE for the moment, but need to change that
> back to the FILE_UPLOAD_TEMP_DIR soon.
>
> cheers, tom
>
> On 14 Jul., 04:54, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > Looks like apache does not have write access to that directory.
> > Try setting a different directory where Apache will have appropriate
> > access, use the FILE_UPLOAD_TEMP_DIR setting for that.
>
> > On Jul 14, 11:48 am, tom <[EMAIL PROTECTED]> wrote:
>
> > > Hi,
>
> > > I have a problem with file uploads which are bigger than 2.5 MBs. When
> > > I use files which are smaller than 2.5 MBs, the files save as
> > > expected. As soon as they are bigger than that, I get an IOError (see
> > > traceback further down). I have checked that i have write and delete
> > > permissions on this directory. When I change the
> > > FILE_UPLOAD_MAX_MEMORY_SIZE the uploads are working fine.
>
> > > Help would be very much appreciated. :)
>
> > > Cheers, Tom
>
> > > """
> > > Environment:
>
> > > Request Method: POST
> > > Request URL:http://localhost:8000/admin/ads/ad/11/
> > > Django Version: 0.97-pre-SVN-unknown
> > > Python Version: 2.5.1
> > > Installed Applications:
> > > ['django.contrib.auth',
> > >  'django.contrib.contenttypes',
> > >  'django.contrib.sessions',
> > >  'django.contrib.sites',
> > >  'django.contrib.admin',
> > >  'django.contrib.flatpages',
> > >  'django.contrib.comments',
> > >  'our.aps']
> > > Installed Middleware:
> > > ('django.middleware.common.CommonMiddleware',
> > >  'django.contrib.sessions.middleware.SessionMiddleware',
> > >  'django.contrib.auth.middleware.AuthenticationMiddleware',
> > >  'django.middleware.cache.CacheMiddleware',
> > >  'django.middleware.doc.XViewMiddleware',
> > >  'our.middleware.threadlocals.ThreadLocals',
> > >  'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware')
>
> > > Traceback:
> > > File "/Library/Python/2.5/site-packages/django/core/handlers/base.py"
> > > in get_response
> > >   86.                 response = callback(request, *callback_args,
> > > **callback_kwargs)
> > > File "/Library/Python/2.5/site-packages/django/contrib/admin/views/
> > > decorators.py" in _checklogin
> > >   62.             return view_func(request, *args, **kwargs)
> > > File "/Library/Python/2.5/site-packages/django/views/decorators/
> > > cache.py" in _wrapped_view_func
> > >   44.         response = view_func(request, *args, **kwargs)
> > > File "/Library/Python/2.5/site-packages/django/contrib/admin/views/
> > > main.py" in change_stage
> > >   338.             new_object = manipulator.save(new_data)
> > > File "/Library/Python/2.5/site-packages/django/db/models/
> > > manipulators.py" in save
> > >   106.                 f.save_file(new_data, new_object, self.change
> > > and self.original_object or None, self.change, rel=False, save=False)
> > > File "/Library/Python/2.5/site-packages/django/db/models/fields/
> > > __init__.py" in save_file
> > >   855.             func(file_name, file, save)
> > > File "/Library/Python/2.5/site-packages/django/db/models/fields/
> > > __init__.py" in 
> > >   817.         setattr(cls, 'save_%s_file' % self.name, lambda
> > > instance, filename, raw_field, save=True:
> > > instance._save_FIELD_file(self, filename, raw_field, save))
> > > File "/Library/Python/2.5/site-packages/django/db/models/base.py" in
> > > _save_FIELD_file
> > >   532.             file_move_safe(raw_field.temporary_file_path(),
> > > full_filename)
> > > File "/Library/Python/2.5/site-packages/django/core/files/move.py" in
> > > file_move_safe
> > >   40.         file_move(old_file_name, new_file_name)
> > > File "/System/Library/Frameworks/

Re: IOError with files uploads bigger than 2.5 MB

[Julien Phalip]

Looks like apache does not have write access to that directory.
Try setting a different directory where Apache will have appropriate
access, use the FILE_UPLOAD_TEMP_DIR setting for that.

On Jul 14, 11:48 am, tom <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a problem with file uploads which are bigger than 2.5 MBs. When
> I use files which are smaller than 2.5 MBs, the files save as
> expected. As soon as they are bigger than that, I get an IOError (see
> traceback further down). I have checked that i have write and delete
> permissions on this directory. When I change the
> FILE_UPLOAD_MAX_MEMORY_SIZE the uploads are working fine.
>
> Help would be very much appreciated. :)
>
> Cheers, Tom
>
> """
> Environment:
>
> Request Method: POST
> Request URL:http://localhost:8000/admin/ads/ad/11/
> Django Version: 0.97-pre-SVN-unknown
> Python Version: 2.5.1
> Installed Applications:
> ['django.contrib.auth',
>  'django.contrib.contenttypes',
>  'django.contrib.sessions',
>  'django.contrib.sites',
>  'django.contrib.admin',
>  'django.contrib.flatpages',
>  'django.contrib.comments',
>  'our.aps']
> Installed Middleware:
> ('django.middleware.common.CommonMiddleware',
>  'django.contrib.sessions.middleware.SessionMiddleware',
>  'django.contrib.auth.middleware.AuthenticationMiddleware',
>  'django.middleware.cache.CacheMiddleware',
>  'django.middleware.doc.XViewMiddleware',
>  'our.middleware.threadlocals.ThreadLocals',
>  'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware')
>
> Traceback:
> File "/Library/Python/2.5/site-packages/django/core/handlers/base.py"
> in get_response
>   86.                 response = callback(request, *callback_args,
> **callback_kwargs)
> File "/Library/Python/2.5/site-packages/django/contrib/admin/views/
> decorators.py" in _checklogin
>   62.             return view_func(request, *args, **kwargs)
> File "/Library/Python/2.5/site-packages/django/views/decorators/
> cache.py" in _wrapped_view_func
>   44.         response = view_func(request, *args, **kwargs)
> File "/Library/Python/2.5/site-packages/django/contrib/admin/views/
> main.py" in change_stage
>   338.             new_object = manipulator.save(new_data)
> File "/Library/Python/2.5/site-packages/django/db/models/
> manipulators.py" in save
>   106.                 f.save_file(new_data, new_object, self.change
> and self.original_object or None, self.change, rel=False, save=False)
> File "/Library/Python/2.5/site-packages/django/db/models/fields/
> __init__.py" in save_file
>   855.             func(file_name, file, save)
> File "/Library/Python/2.5/site-packages/django/db/models/fields/
> __init__.py" in 
>   817.         setattr(cls, 'save_%s_file' % self.name, lambda
> instance, filename, raw_field, save=True:
> instance._save_FIELD_file(self, filename, raw_field, save))
> File "/Library/Python/2.5/site-packages/django/db/models/base.py" in
> _save_FIELD_file
>   532.             file_move_safe(raw_field.temporary_file_path(),
> full_filename)
> File "/Library/Python/2.5/site-packages/django/core/files/move.py" in
> file_move_safe
>   40.         file_move(old_file_name, new_file_name)
> File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/shutil.py" in move
>   199.             copy2(src,dst)
> File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/shutil.py" in copy2
>   91.     copyfile(src, dst)
> File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/shutil.py" in copyfile
>   46.         fsrc = open(src, 'rb')
>
> Exception Type: IOError at /admin/ads/ad/11/
> Exception Value: [Errno 2] No such file or directory: '/var/folders/g2/
> g2k+MI0fHlCR7GvjpacMPU+++TI/-Tmp-/tmpR3rxkC.upload'
>
> """
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: ANN: Join us at a sprint!

[Julien Phalip]

... and for the impatient ones, there's a sprint starting... now! It
is physically taking place at Europython, but as for other sprints any
one can join from all around the world. For for info:
http://code.djangoproject.com/wiki/SprintEuroPython2008

On Jul 12, 8:25 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Howdy folks --
>
> Django 1.0 is about two months away — time to get cracking!
>
> To help get everything done by the deadline, we'll be holding a series
> of sprints. Over the next six weeks we'll hold sprints in Sausalito,
> Lawrence, Austin, and Portland, and virtually all over the world.
>
> Each sprint day we'll devote at least 24 hours of focused work. Each
> sprint will be on a Friday, though work will likely continue at a fair
> clip into the weekend.
>
> Anybody is invited to participate and contribute. If you've never
> contributed to Django before, this is a perfect way to start.
>
> If you're interested, check outhttp://code.djangoproject.com/wiki/Sprints, 
> and see the details of
> each particular sprint:
>
>     * July 18: Sausalito, 
> CA:http://code.djangoproject.com/wiki/SprintSausalitoJuly2008
>     * August 1: Location TBA, probably in the Washington, DC or
> Baltimore, MD area.
>     * August 8: Lawrence, 
> KS:http://code.djangoproject.com/wiki/SprintLawrenceAugust2008
>     * August 15: Austin, 
> TX:http://code.djangoproject.com/wiki/SprintAustinAugust2008
>     * August 22: Portland, 
> OR:http://code.djangoproject.com/wiki/SprintPortlandAugust2008
>
> We hope you'll join us — in person, or virtually!
>
> Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: django-registration

[Julien Phalip]

django-registration uses the standard settings for sending emails. You
need to use the following settings:

EMAIL_USE_TLS   (Set to True if using Gmail)
EMAIL_HOST
EMAIL_HOST_USER
EMAIL_HOST_PASSWORD
EMAIL_PORT

More info is available here: 
http://www.djangoproject.com/documentation/settings/

On Jul 11, 8:16 pm, thomas schreiber <[EMAIL PROTECTED]> wrote:
> Is there a reason emails aren't being sent when running this app on
> localhost? Is there more that needs to be done to get the email
> sending part working other then what is included with django-
> registration? I'll come back to it later today.
>
> Thanks,
> Tom
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: "ImportError No module named django"

[Julien Phalip]

Apparently Django is not present in the PYTHONPATH and therefore not
reachable by Python.
I'm not a Mac user, but some help can be found on google.

Try there for example:
http://antoniocangiano.com/2007/12/22/how-to-install-django-with-mysql-on-mac-os-x/
http://www.rhonabwy.com/wp/2006/07/20/installing-django-on-macos-x-development-version/

In the first link, the section "Telling Python where Django is" looks
like what you're after.

Cheers,

Julien

On Jul 9, 12:34 pm, MadMax007 <[EMAIL PROTECTED]> wrote:
> Ok, for the PYTHONPATH I got:
>
> >>> import sys
> >>> print sys.path
>
> ['', '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python25.zip', '/System/Library/Frameworks/Python.framework/Versions/
> 2.5/lib/python2.5', '/System/Library/Frameworks/Python.framework/
> Versions/2.5/lib/python2.5/plat-darwin', '/System/Library/Frameworks/
> Python.framework/Versions/2.5/lib/python2.5/plat-mac', '/System/
> Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-
> mac/lib-scriptpackages', '/System/Library/Frameworks/Python.framework/
> Versions/2.5/Extras/lib/python', '/System/Library/Frameworks/
> Python.framework/Versions/2.5/lib/python2.5/lib-tk', '/System/Library/
> Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload', '/
> Library/Python/2.5/site-packages', '/System/Library/Frameworks/
> Python.framework/Versions/2.5/Extras/lib/python/PyObjC']
>
>
>
> Hope this tells you something, I relatively new to Apple computers so
> I feel a bit lost, and to top things off, I'm new to Python as well :
> (
>
> On Jul 8, 5:42 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > This means that Django is not in the PYTHONPATH. To check what's in
> > that path, run the following in Python:
>
> > >>> import sys
> > >>> print sys.path
>
> > On Jul 9, 9:35 am, Juanjo Conti <[EMAIL PROTECTED]> wrote:
>
> > > How did you exactly install it?
> > > Which folders are in your PYTHONPATH?
>
> > > Juanjo
> > > --
> > > mi blog:http://www.juanjoconti.com.ar
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Import issues since newforms-admin

[Julien Phalip]

Ok, I've just opened a ticket and posted some code illustrating the
issue:
http://code.djangoproject.com/ticket/7684

Thanks,

Julien

On Jul 9, 2:14 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Tue, 2008-07-08 at 21:10 -0700, Julien Phalip wrote:
> > Thanks for the tip Malcolm.
>
> > I've prepared some very simple code to illustrate the problem. I can't
> > find a way to attach files in this mailing list. Should I open a
> > ticket and post it there?
>
> Yes. Trac is the only place where things will not be forgotten.
>
> Regards,
> Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Import issues since newforms-admin

[Julien Phalip]

Thanks for the tip Malcolm.

I've prepared some very simple code to illustrate the problem. I can't
find a way to attach files in this mailing list. Should I open a
ticket and post it there?

Thanks,

Julien

On Jul 9, 9:50 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Tue, 2008-07-08 at 16:20 -0700, Julien Phalip wrote:
> > Hi,
>
> > There's an issue that arose as I upgraded an external app of mine to
> > newforms-admin.
>
> > I created the conventional admin.py, which does all the registration
> > business, and did "import admin" in the module's __init__.py
>
> > After I did that, I got some import errors at compilation time (or
> > say, project's launching time):
>
> > "ImportError: cannot import name MenuItem"
>
> > "MenuItem" is in the external app (freshly upgraded to nfa), and the
> > import that raises the error is made in the project's app.
>
> It's a bit (for me, at least) to keep track of what structure you're
> describing here. You are using the word "project" to mean something that
> isn't clear. Could you give a small layout of the directory structure
> please.
>
> It's not impossible to imagine something like the problem you're
> describing happening depending upon import paths. Remember that when you
> do "from foo import models", Python first has to parse and execute the
> code in "foo/__init__.py", so things might not be fully constructed.
> But, again, it's hard to tell without concrete code. If you can
> construct a very small example that demonstrates the problem (like,
> literally, as few lines as possible. To the point that if you remove any
> more lines, the problem goes away) then you've got something you can put
> in a bug report because then other people can try to repeat the problem
> and diagnose it.
>
> I'm not intimately familiar with how newforms is doing imports or
> recommended practices over there, but if this type of problem is
> cropping up, it's worth knowing about it so that we can either document
> "don't do that" or get things fixed if possible.
>
> Again, I'm not saying that what you're seeing is a bug or necessarily a
> problem in Django. I don't understand the problem you're describing from
> the English-language version. Code speaks more clearly here, I think.
>
> Regards,
> Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: "ImportError No module named django"

[Julien Phalip]

Hi,

This means that Django is not in the PYTHONPATH. To check what's in
that path, run the following in Python:

>>> import sys
>>> print sys.path


On Jul 9, 9:35 am, Juanjo Conti <[EMAIL PROTECTED]> wrote:
> How did you exactly install it?
> Which folders are in your PYTHONPATH?
>
> Juanjo
> --
> mi blog:http://www.juanjoconti.com.ar
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Import issues since newforms-admin

[Julien Phalip]

Hi,

There's an issue that arose as I upgraded an external app of mine to
newforms-admin.

I created the conventional admin.py, which does all the registration
business, and did "import admin" in the module's __init__.py

After I did that, I got some import errors at compilation time (or
say, project's launching time):

"ImportError: cannot import name MenuItem"

"MenuItem" is in the external app (freshly upgraded to nfa), and the
import that raises the error is made in the project's app.

The external app was included at the top of the INSTALLED_APPS
setting. Putting it at the end of INSTALLED_APPS solved the issue.

I thought that the order didn't matter in INSTALLED_APPS. Have I
missed something or have I possibly misconfigured my external app or
my project's apps?

Is that a known issue (and if so, what's the proper way around it?),
or is that worth filing a ticket?

Thanks!

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---