Re: Model Form crashing on Foreign Key
I feel like I could jump out of the window... Just spent 4 hours of debugging :/ Any idea which is the last revision which is not affected by this bug? On 11 Janv., 07:02, Sontek wrote: > On Jan 10, 6:17 pm, Sontek wrote: > > > On Jan 10, 12:23 pm, Sontek wrote: > > > > So I'm trying to create a new feed within the Admin page and its > > > crashing with the error IntegrityError: lifestream_feed.lifestream_id > > > may not be NULL, the call stack is... form['lifestream'] is set but > > > form.instance.lifestream is not. Here is the code: > > This is a bug in HEAD -- 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: DRY: max length not taken from Model.field when using ModelForm
Tomasz, it was obvious for me too, however, I had defined a form, which had some fields overridden, but some not- I was hoping that options for fields that were not overridden were preserved, but due to specific way admin interface handles forms, required class wasn't added to my custom form fields. That's why I thought other field options were not taken into account. Reinis On 7 nov., 21:27, Tomasz Zieliński wrote: > On 7 Lis, 18:25, fest wrote: > > > From my experience, max_length is not taken into account when you > > override modelfieldin formfield. > > This is (and was, when I first time faced it) quite obvious for me . > IfModelFormwas modifying overridden fields, the whole concept > of overriding would be useless. > > On the other hand it would be nice if we could write something like: > > first_name = forms.CharField(max_length=copy_from_model) > > -- > Tomasz Zielińskihttp://pyconsultant.eu --~--~-~--~~~---~--~~ 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: DRY: max length not taken from Model.field when using ModelForm
>From my experience, max_length is not taken into account when you
override model field in form field. In this case I don't know of any
trivial way to read other field properties from model description.
Regards, Reinis
On 20 okt., 17:54, Karen Tracey wrote:
> On Thu, Oct 15, 2009 at 12:30 PM, Gerard wrote:
>
> > Hi All,
>
> > It seems the max_lenght from the model definition is not respected
> > thoughout
> > the form that's created when using Modelform.
>
> > company_name = models.CharField(max_length=75)
>
> > Is this correct or am I missing something?
>
> This is not correct. For this model:
>
> class Tag(models.Model):
> name = models.CharField(max_length=4)
>
> I see max_length being respected in the corresponding ModelForm:
>
> Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
> [GCC 4.3.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> (InteractiveConsole)>>> from ttt.models import Tag
> >>> from django import forms
> >>> class TForm(forms.ModelForm):
>
> ... class Meta:
> ... model = Tag
> ...>>> tf = TForm({'name':'Too long'})
> >>> tf.is_valid()
> False
> >>> tf.errors
>
> {'name': [u'Ensure this value has at most 4 characters (it has 8).']}
>
> >>> quit()
>
> What exactly did you try that led you to the conclusion that max_length is
> not respected by ModelForms?
>
> Karen
--~--~-~--~~~---~--~~
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: Deploying Django to production environment
Hi John, It doesn't really matter where you place your application code- just don't put it in a place accessible by your web server, so nobody can access your source code. I have apache configured to serve php websites from /var/sharedwww/ site1/www, but my django site resides in /var/sharedwww/site2/. I basically have svn repos on my server, and I just cd'd to / var/sharedwww/site2 and checked out my repository. So eventually my application layout will be as follows: /var/sharedwww/site2/ --- (django code resides in this directory) ---media ---logs ---django.wsgi Of course, webserver is configured not to show any python code in this directory. You can read about django deployment on apache with mod_wsgi here: http://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/#howto-deployment-modwsgi Reinis On 4 nov., 06:19, JohnL wrote: > Hi All, > > I just joined linode and followed there instructions in setting up > Django athttp://library.linode.com/lamp-guides/ubuntu-9.10-karmic/. > > > ServerAdmin squ...@bucknell.net > ServerName bucknell.net > ServerAliaswww.bucknell.net > DocumentRoot /srv/www/bucknell.net/public_html/ > ErrorLog /srv/www/bucknell.net/logs/error.log > CustomLog /srv/www/bucknell.net/logs/access.log combined > > > My question is where do I place my django application files? How can > I setup something like my development machine where I have a > repository on assembla.com where I can check in and out easily to > deploy? > > Thank you, > John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
DRY in django.contrib.auth
Hello,
I'm not sure if I should post this message in django-developers or
here, but before I bother django developers, I wanted to discuss this
issue with django users.
I stumbled across this one when I was creating a custom User class, by
inheriting from django's built in User class. I extended User,
extended User admin, and even created a custom add form, but I just
couldn't get my form fields displayed. Having fair experience with
django forms, I thought, that these fields should automatically be
rendered in form. When I took a look at the form's code, I immediately
understood what's wrong with my approach- form fields were hardcoded
in django\contrib\admin\templates\admin\auth\user\add_form.html
Looking at the code, I see there is some duplication in
contrib.auth.forms file- help text and field names are both specified
in forms and in template- see yourself:
forms.py
class UserCreationForm(forms.ModelForm):
"""
A form that creates a user, with no privileges, from the given
username and password.
"""
username = forms.RegexField(label=_("Username"), max_length=30,
regex=r'^\w+$',
help_text = _("Required. 30 characters or fewer. Alphanumeric
characters only (letters, digits and underscores)."),
error_message = _("This value must contain only letters,
numbers and underscores."))
password1 = forms.CharField(label=_("Password"),
widget=forms.PasswordInput)
password2 = forms.CharField(label=_("Password confirmation"),
widget=forms.PasswordInput)
add_form.html
{% trans "First, enter a username and password. Then, you'll be
able to edit more user options." %}
{{ form.username.errors }}
{# TODO: get required class on label_tag #}
{% trans 'Username' %}: {{ form.username }}
{{ form.username.help_text }}
{{ form.password1.errors }}
{# TODO: get required class on label_tag #}
{% trans 'Password' %}: {{ form.password1 }}
{{ form.password2.errors }}
{# TODO: get required class on label_tag #}
{% trans 'Password
(again)' %}: {{ form.password2 }}
{% trans 'Enter the same password as above, for
verification.' %}
(I left out irrelevant parts of code)
Shouldn't the add_form.html be converted to something like:
{% for field in form %}
{{ field.errors }}
{% trans field.label_tag %}:{{ field }}
{{ field.help_text }}
{% endfor %}
In my opinion this approach is more flexible and avoids unneccesary
duplication, while maintaining the same functionality and appearance.
And my point is- should I post this message to django-developers (I
know, some of the developers should read this list too) or keep my
thoughts to myselft? :>
Reinis
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
