get_FOO_display() for generic/variable choice fields
I have a model ContactDetail with two choice fields,
ContactDetail.dialing_code and ContactDetail.country. These use the
standard tuples ('AU', 'Australia') and so on.
I know I can use get_country_display() and get_dialing_code_display()
to show the longer values, but is there a more generic version where
the field name is replaced with a variable?
For example, I want to create a customised .csv file from the model
data. I can loop through the fields from my model and get the shorter
attribute values without any problems. However I'd like to do
something like this:
obj = queryset[my_item] # an instance of ContactDetail()
model = queryset.model # ContactDetail() itself
for field in model._meta.fields:
val = getattr(obj, field.name) # gets the shorter version
if field.choices:# if field is ChoiceField,
convert data
to display mode
val = obj.get_field_display()
row.append(val)
Obviously the 'val = obj.get_field_display()' line doesn't work!
Is there a generic way of doing this (something like
obj.get_display(fieldname) ?) or am I going to have to hard code
separate checks for get_country_display() and
get_dialing_code_display()?
Ideally I would like to use this particular function for other models
and keep the fields as generic as possible.
--
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: get_FOO_display() for generic/variable choice fields
My Python-expert partner suggested a clever workaround as follows:
As I'm already running through the model._meta.fields beforehand to
create header row for my .csv file, I can build a dictionary of the
choices to refer to later.
choices_lookup_dict = {}
header_row = []
for field in model._meta.fields:
# create header row for csv file
header_row.append(field.name)
# Add lookup dictionary of choices to dictionary of fields
# i.e. creating a dictionary of dictionaries for each choice field
if field.choices:
choices_lookup_dict[field.name] = dict(field.choices)
This could be quite expensive for large choice tuples such as country
lists, but at least we're only calling it once.
So now in my main loop I can use the following code to lookup my
verbose choice value:
for field in model._meta.fields:
val = getattr(obj, field.name)
if field.choices:
val = choices_lookup_dict[field.name][val]
row.append(val)
We assume that get_FOO_display() must be doing something like this
anyway!
--
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.
Internationalization - top level locale .mo files generated but not recognised in Django 1.5
I am currently upgrading a project from Django 1.3 to 1.5 and having
trouble getting Django to recognise my compiled .mo translations.
My project is structured as follows:
/toplevelfolder
/myproject
/app1
/app2
/app3
/templates
/app1templates
/app2templates
/app3templates
/locale
And I have the following in my settings.py file:
LOCALE_PATHS = (
'/path/to/toplevelfolder/locale'
)
When I run the 'makemessages -l de' command in /toplevelfolder, the
django.po file is created correctly in
the toplevelfolder/locale/de/LC_MESSAGES folder with no errors. I add a
test string (in this case for a form label) such as:
#: .\myproject\app1\usersignupform.py:56
msgid "I accept the terms and conditions."
msgstr "I accept the German terms and conditions"
Running 'compilemessages' creates the django.mo file with no errors, so I
restart my test server as usual.
However the test translation string above does not show on the form label -
only the Django in-house translations (e.g. basic form validation strings)
are being displayed (so the language is definitely set to German).
Interestingly I tried using lower level /locale folders within the app1,
app2 folders and the strings were successfully compiled and displayed. But
obviously this only covers the strings in my app code - when I try doing
the same within my separate template folder, the files are generated ok but
just don't display on the page after compiling, like at the top level. In
any case, there are a dozen apps in my project and many shared strings - it
would obviously be ideal to get makemessages working at the top level and
collate them into one django.po file for our translator.
I am using {% load i18n %} in all the relevant templates and the top level
method above worked perfectly well with the same project in Django 1.3, so
it is unlikely to be a typo in my template or app code. Should it matter
where the template directory is, as long as it's within the scope of where
I'm calling django-admin.py (i.e. /toplevelfolder)?
For completeness: I have installed gettext-tools-0.17 for Windows and added
the /bin files to my PATH variable (i.e. running xgettext --version from
the command line is fine).
I also tried refreshing my Middleware cache by commenting out
'django.middleware.locale.LocaleMiddleware' in my settings and then putting
it back in again (as I saw suggested elsewhere), with no luck.
I'd be grateful for any suggestions! Please ask if anything is unclear.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Internationalization - top level locale .mo files generated but not recognised in Django 1.5
To follow up on this - when I moved my locale files to a completely new
location and used a different path in my LOCALE_PATHS settings, the
translations worked fine. I think it may have been a folder permissions
issue.
On Tuesday, August 6, 2013 5:02:03 PM UTC+1, katstevens wrote:
>
> I am currently upgrading a project from Django 1.3 to 1.5 and having
> trouble getting Django to recognise my compiled .mo translations.
>
> My project is structured as follows:
>
> /toplevelfolder
> /myproject
> /app1
> /app2
> /app3
> /templates
> /app1templates
> /app2templates
> /app3templates
> /locale
>
> And I have the following in my settings.py file:
>
> LOCALE_PATHS = (
> '/path/to/toplevelfolder/locale'
> )
>
> When I run the 'makemessages -l de' command in /toplevelfolder, the
> django.po file is created correctly in
> the toplevelfolder/locale/de/LC_MESSAGES folder with no errors. I add a
> test string (in this case for a form label) such as:
>
> #: .\myproject\app1\usersignupform.py:56
> msgid "I accept the terms and conditions."
> msgstr "I accept the German terms and conditions"
>
> Running 'compilemessages' creates the django.mo file with no errors, so I
> restart my test server as usual.
>
> However the test translation string above does not show on the form label
> - only the Django in-house translations (e.g. basic form validation
> strings) are being displayed (so the language is definitely set to German).
>
> Interestingly I tried using lower level /locale folders within the app1,
> app2 folders and the strings were successfully compiled and displayed. But
> obviously this only covers the strings in my app code - when I try doing
> the same within my separate template folder, the files are generated ok but
> just don't display on the page after compiling, like at the top level. In
> any case, there are a dozen apps in my project and many shared strings - it
> would obviously be ideal to get makemessages working at the top level and
> collate them into one django.po file for our translator.
>
> I am using {% load i18n %} in all the relevant templates and the top level
> method above worked perfectly well with the same project in Django 1.3, so
> it is unlikely to be a typo in my template or app code. Should it matter
> where the template directory is, as long as it's within the scope of where
> I'm calling django-admin.py (i.e. /toplevelfolder)?
>
> For completeness: I have installed gettext-tools-0.17 for Windows and
> added the /bin files to my PATH variable (i.e. running xgettext --version
> from the command line is fine).
>
> I also tried refreshing my Middleware cache by commenting out
> 'django.middleware.locale.LocaleMiddleware' in my settings and then putting
> it back in again (as I saw suggested elsewhere), with no luck.
>
> I'd be grateful for any suggestions! Please ask if anything is unclear.
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.
RegistrationForm subclass not showing up
Hi - I'm new to Django and am using django-registration to set up new
users.
The basic RegistrationForm shows up fine in my template (which just
uses {{ form.as_table }} to generate fields inside the form HTML), but
I now want to use the RegistrationFormTermsOfService subclass instead.
I set it as a parameter in urls.py as follows:
url(r'^register/$',
register,
{'form_class':
RegistrationFormTermsOfService},
name='registration_register'),
... but the original RegistrationForm is still showing instead. Any
ideas why this would be? Do I have to remove the default 'form_class'
value in the register declaration in views.py (as that still gives
RegistrationForm as the default)? Or do I need to alter my template?
I'm sure I'm missing something really obvious - any help gratefully
received.
Kat
--
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: RegistrationForm subclass not showing up
Thanks for your answer, but unfortunately that hasn't helped - on
further investigation I think the problem is somewhere else, as the
original RegistrationForm class instance (in registration.forms)
doesn't seem to be being called correctly by registration.views (so no
wonder RegistrationFormTermsOfService isn't working!). I tried making
some small changes to the labels in the RegistrationForm class and it
is still displaying the default label values in my template. For
example, the class declaration now looks like:
class RegistrationForm(forms.Form):
# all the other fields
# ...
password1 =
forms.CharField(widget=forms.PasswordInput(attrs=attrs_dict,
render_value=False),
label=_(u'different password label'))
In registration.views I've imported the form as follows
from registration.forms import RegistrationForm
And used the default view declaration:
def register(request, success_url=None,
form_class=RegistrationForm, profile_callback=None,
template_name='registration/registration_form.html',
extra_context=None):
if request.method == 'POST':
# do post stuff
else:
# instantiate blank form
form = form_class()
Finally, on the registration_form.html template I've tried calling the
fields explicitly rather than using the form.as_table tag:
{{ form.password1.label_tag }}
{{ form.password1 }}
The page displays these fields fine, yet the label still gives the
default label value of 'password' instead of 'different password
label'. I'm not getting any syntax errors, and I've rebooted my server
for good measure with the same results. Therefore I assume that either
form = form_class() isn't actually instantiating RegistrationForm
properly in the view, or there is some sort of overriding default
being called from a different location (maybe django.contrib.auth?).
Also - I can't see the form_call field that you mention - does this
refer to the parameter 'form_class=RegistrationForm' I've used above
in my registration view?
Thanks again!
On Jul 8, 7:08 am, CareerDhaba tech wrote:
> Hi Kat,
>
> You have to tell the your registration view to use the
> RegistrationFormTermsofService. First, import that class from forms and
> change your form_call from None to to RegistrationFormTermsofService.
>
> Hope this helps.
>
>
>
>
>
>
>
> On Thu, Jul 7, 2011 at 5:34 PM, katstevens wrote:
> > Hi - I'm new to Django and am using django-registration to set up new
> > users.
>
> > The basic RegistrationForm shows up fine in my template (which just
> > uses {{ form.as_table }} to generate fields inside the form HTML), but
> > I now want to use the RegistrationFormTermsOfService subclass instead.
>
> > I set it as a parameter in urls.py as follows:
> > url(r'^register/$',
> > register,
> > {'form_class':
> > RegistrationFormTermsOfService},
> > name='registration_register'),
>
> > ... but the original RegistrationForm is still showing instead. Any
> > ideas why this would be? Do I have to remove the default 'form_class'
> > value in the register declaration in views.py (as that still gives
> > RegistrationForm as the default)? Or do I need to alter my template?
>
> > I'm sure I'm missing something really obvious - any help gratefully
> > received.
>
> > Kat
>
> > --
> > 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.
--
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: RegistrationForm subclass not showing up
I think that's it! I'm using v0.7 and will upgrade now - thanks for the heads up. On Jul 8, 6:52 pm, CareerDhaba tech wrote: > I believe you are using an older version of django_registration, since there > is no reference to the backend in your code. The backend is an addition in > the latest (0.8) version of django_registration. > > Did you download the code from > here?http://readthedocs.org/docs/django-registration/en/latest/index.html > -- 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: RegistrationForm subclass not showing up
OK I must have missed something fundamental. I installed v0.8 and
having started all over again, I only made one change - adding an
extra field to the basic RegistrationForm class in registration.forms
- this isn't showing up on my template either!
Looking over my code, I've found it's not just the Registration form
class - when I try altering the default label in e.g.
PasswordResetForm (from django.contrib.auth.forms) the change doesn't
show up in my template either ( {{ form.email.label_tag }} ), it still
displays the default. Is there another mysterious source that django
is getting the form class declaration from instead, or is it just
ignoring my changes for some reason? I'm not getting any errors and
the form itself still works correctly. I haven't changed any of the
default code for PasswordResetForm (urls, views, forms) except that
one label. I can't understand this behaviour at all.
On Jul 11, 10:46 am, katstevens wrote:
> I think that's it! I'm using v0.7 and will upgrade now - thanks for
> the heads up.
>
> On Jul 8, 6:52 pm, CareerDhaba tech wrote:
>
>
>
>
>
>
>
> > I believe you are using an older version of django_registration, since there
> > is no reference to the backend in your code. The backend is an addition in
> > the latest (0.8) version of django_registration.
>
> > Did you download the code from
> > here?http://readthedocs.org/docs/django-registration/en/latest/index.html
--
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: RegistrationForm subclass not showing up
Thank you for your help Andre - I've now worked out what the problem
was. I was editing the wrong copy of the source code (it happens to
everyone at some point!) so no wonder the changes were not
happening... In the end I just created a completely new url path (i.e.
not 'accounts/register') and called registration.views with a
completely new form class in the dictionary parameter.
Here's my final code with the RegistrationForm for reference. In my
project's urls.py I added the following lines:
import registration.backends.default.urls#
django-registration urls
from registration.views import register#
django-registration view
from myapp.newform import MyNewRegistrationForm # my own
customised form
urlpatterns = patterns('',
url(r'^accounts/', include(registration.backends.default.urls)),
url(r'^accounts/registration/$', register, {'backend':
'registration.backends.default.DefaultBackend', 'form_class':
MyNewRegistrationForm },
name='registration_register'),
I just copied the code from the original RegistrationForm class to
myapp.newform and added my customised fields, including the
TermsOfService field I originally wanted...
On Jul 11, 2:13 pm, Andre Terra wrote:
> My guess is that there's another module somewhere in your PYTHONPATH from
> which django is importing these forms.
>
> Also, don't edit registration.forms, subclass the form instead.
>
> You can also try {{ form.as_p }} to make sure the problem isn't in the
> template.
>
> You can raise an exception somewhere in your code to try to find where in
> the python path the module lives. Try something like
>
> def your_view(request):
> # ...
> # your current code
> # ...
> from registration import forms
> assert False, forms.__file__
>
> Good luck!
>
> Cheers,
> André
>
>
>
>
>
>
>
> On Mon, Jul 11, 2011 at 8:45 AM, katstevens wrote:
> > OK I must have missed something fundamental. I installed v0.8 and
> > having started all over again, I only made one change - adding an
> > extra field to the basic RegistrationForm class in registration.forms
> > - this isn't showing up on my template either!
>
> > Looking over my code, I've found it's not just the Registration form
> > class - when I try altering the default label in e.g.
> > PasswordResetForm (from django.contrib.auth.forms) the change doesn't
> > show up in my template either ( {{ form.email.label_tag }} ), it still
> > displays the default. Is there another mysterious source that django
> > is getting the form class declaration from instead, or is it just
> > ignoring my changes for some reason? I'm not getting any errors and
> > the form itself still works correctly. I haven't changed any of the
> > default code for PasswordResetForm (urls, views, forms) except that
> > one label. I can't understand this behaviour at all.
>
> > On Jul 11, 10:46 am, katstevens wrote:
> > > I think that's it! I'm using v0.7 and will upgrade now - thanks for
> > > the heads up.
>
> > > On Jul 8, 6:52 pm, CareerDhaba tech wrote:
>
> > > > I believe you are using an older version of django_registration, since
> > there
> > > > is no reference to the backend in your code. The backend is an addition
> > in
> > > > the latest (0.8) version of django_registration.
>
> > > > Did you download the code from here?
> >http://readthedocs.org/docs/django-registration/en/latest/index.html
>
> > --
> > 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.
--
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.
