Admin ignores null=True in ForeignKey

[David Walker]

If I create a ForeignKey relationship between two Models with null=True, the
Admin seems to still insist on there being a foreign object to link to.

For example, I created a very simple ForeignKey relationship from Things to
Types:

from django.db import models

class Type(models.Model):
  name = models.CharField(max_length=30)

class Thing(models.Model):
  type_of_thing = models.ForeignKey(Type, null=True)
  name = models.CharField(max_length=30)

In the console, I can happily create Type-less Things:

>>> from ni.models import *
>>> x = Thing()
>>> x.name = 'Untyped thing'
>>> x.type = None
>>> x.save()
>>> all_things = Thing.objects.all()
>>> print all_things
[]
>>> print all_things[0].type_of_thing
None

In the Admin, however, when I try to add a new Thing, or even edit and save
the existing Thing, the type_of_thing field is shown as required and saving
without setting it causes "This field is required." to be displayed and the
Thing not to be saved.

Am I doing something wrong?

-- 
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.

Localisation

[David Walker]

Despite reading round and round in circles in the documentation, I am
completely baffled about localisation and how it works.  I am not
trying to do any translation yet, but want to code money and date
formats right so that I don't have to rewrite things later.

It isn't even clear to me which locale things are being localised to.
I had presumed that everything would be localised to the browser's
locale, using the language setting, however it seems to be localised
to the LANGUAGE_CODE setting from settings.py.  Am I doing something
wrong?

Any help would be gratefully received.

-- 
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: to iterate over two lists simultaneously in *.html

[David Walker]

As masklinn says, zip: http://docs.python.org/library/functions.html#zip

Combine the two lists in python into one list of pairs (tuples).
change the render_to_response line to:
render_to_response(filter_obj.html', {'zipped': zip(obj1, obj2),
'q':query})
zip discards any elements that are left over in the longer list.

and the the {% for %} becomes:
{% for smth1, smth2 in zipped %}

You don't need the {% if %} because the for already does that:
http://docs.djangoproject.com/en/dev/ref/templates/builtins/#for

Cheers,

Dave


On Jan 16, 8:25 am, gintare  wrote:
> Hello,
>
> I am sorry for asking a simple question.
> (I read other answer bout iteration in several items in this user
> group - they are too complicated for me. I have no time to study
> Django deeper. )
> I want to iterate over two lists simultaneously in form which is
> simple (.html), do not described in models.py or admin.py
>
> ## views.py
> obj1=mod1.filter(field__contains='smth1').order('-date')
> obj2=mod2.filter(field__contains='smth2').order('-date')
>
> return render_to_response('filter_obj.html', {'List1':obj1, 'List2':
> obj2, 'q': query })
>
> ## filter_obj.html
>
> {% if List1 %}
> {%  for smth1, smth2 in List1, List2 %}
> 
>  how to iterate 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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Localisation

[David Walker]

Thanks Lachlan.

The middleware was the bit I was missing.  The only mention of it on
the Django website appears to be on the Middleware page.  Perhaps it
should go on the localisation pages?

The middleware allows the pages to be localised to the browser's
locale, although there are still a number of strange behaviours

There seem to be two main places where date formats originate.  They
are set in settings.py and in the locale's formats.py
(django.conf.locale..formats).

formats.py sets (amongst others) DATE_FORMAT and SHORT_DATE_FORMAT for
the locale in question (along with a load of other datetime formats).
setings.py sets L10N, and also DATE_FORMAT and SHORT_DATE_FORMAT.

If L10N is True, the SHORT_DATE_FORMAT in settings.py is not used in
rendering, with the localised version from the appropriate formats.py
being used instead.
However, Django uses two versions of DATE_FORMAT.  The settings.py one
defaults to to the US format of 'N j, Y', but can be changed.  The
formats.py one contains the appropriate setting for your locale (but
see en_GB below!).

So, what does all this mean for rendering?  I think that the following
happens (assuming that d is a date):
{{d|date:"SHORT_DATE_FORMAT"}}
produces a localised short date: 'd/m/Y' here in the UK
{{d}}
produces a localised long date: 'j \de F \de Y' in Portugal
{{d|date}}
produces a date based on the settings.DATE_FORMAT ( 'N j, Y'
unless changed), but incredibly the month name is translated to the
browser locale.  This often produces date that no one would ever use
like: Março 10, 2010 (the default setting with a Portuguese browser).
I seem to remember seeing in some documentation somewhere (that I now
can't find) that it was intended that the date filter without
arguments would produce a consistent, machine readable date format.

While it may be useful to have a locale independent date format, this,
to me, has a number of problems:
1. re-using the variable name DATE_FORMAT is bound to cause confusion
2. using a common human format for locale independent machine readable
dates is likely to cause confusion.
3. translating the result renders the whole process pointless.

Meanwhile, the documentation says:
http://docs.djangoproject.com/en/dev/ref/settings/#date-format
Note that if USE_L10N is set to True, then the locale-dictated
format has higher precedence and will be applied instead.
http://docs.djangoproject.com/en/dev/ref/templates/builtins/#date
When used without a format string...the formatting string defined
in the DATE_FORMAT setting will be used, without applying any
localization.

Neither of these statements correctly describe the actual behaviour I
have observed.

To add to my confusion, django.conf.locale.en_GB.formats contains
DATE_FORMAT='N j, Y', whereas I think it should be something like 'j F
Y', 'j N Y' or 'jS F Y'.  The Unicode Common Locale Data Repository
seems to agree with me, plumping for 'd  y' or 'd MMM
y' (obviously these are in a different format).

Have I got this right?
Where do I/we go from here?
Is there a better forum for this?
Can I help improve things by writing bug reports?  enhancements
requests? patches? documentation? or taking part in discussions?

Cheers,

Dave


On Jan 17, 4:39 am, Lachlan Musicman  wrote:
> On Sun, Jan 16, 2011 at 04:23, David Walker  wrote:
> > Despite reading round and round in circles in the documentation, I am
> > completely baffled aboutlocalisationand how it works.  I am not
> > trying to do any translation yet, but want to code money and date
> > formats right so that I don't have to rewrite things later.
>
> > It isn't even clear to me which locale things are being localised to.
> > I had presumed that everything would be localised to the browser's
> > locale, using the language setting, however it seems to be localised
> > to the LANGUAGE_CODE setting from settings.py.  Am I doing something
> > wrong?
>
> I have successfully seen changing the language setting in the/a
> browser work (in Japanese) when it comes tolocalisationof a django
> based site, with LANGUAGE_CODE set to "en".
>
> You may need to send more information, for eg:
>
> which version of django on what platform (these are less important,
> but you never know)
>
> Do you have USE_L10N = True in settings.py?
>
> Do you have 'django.middleware.locale.LocaleMiddleware', in 
> MIDDLEWARE_CLASSES?
>
> cheers
> L.
>
>
>
> > Any help would be gratefully received.
>
> > --
> > 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, sen