Re: Django development version docs

[Thomas B. Higgins]

@Karen,

Oops, sorry. I had an extra folder name in my Tortoise SVN checkout
settings. My mistake.

Thank you for being so efficient at policing nonsense.

Tom

On Feb 2, 11:33 am, Karen Tracey <kmtra...@gmail.com> wrote:
> On Tue, Feb 2, 2010 at 2:25 PM, Thomas B. Higgins
> <thomasbhigg...@gmail.com>wrote:
>
> > I believe the directory structure for Django has changed. So, Writing
> > your first Django app, Part 1,
> >http://docs.djangoproject.com/en/dev/intro/tutorial01/,
> > should refer to site-packages/django/django/bin, not site-packages/
> > django/bin as the path entry. If you all agree I am getting this
> > right, I will create a documentation ticket.
>
> No, the structure hasn't changed. There should not be two levels of 'django'
> in that path. Why do you think there should be?
>
> 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-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: Django development version docs

[Thomas B. Higgins]

@Karen,

Oops, sorry. I had an extra folder name in my Tortoise SVN checkout
settings. My mistake.

Thank you for being so efficient at policing nonsense.

Tom

On Feb 2, 11:33 am, Karen Tracey <kmtra...@gmail.com> wrote:
> On Tue, Feb 2, 2010 at 2:25 PM, Thomas B. Higgins
> <thomasbhigg...@gmail.com>wrote:
>
> > I believe the directory structure for Django has changed. So, Writing
> > your first Django app, Part 1,
> >http://docs.djangoproject.com/en/dev/intro/tutorial01/,
> > should refer to site-packages/django/django/bin, not site-packages/
> > django/bin as the path entry. If you all agree I am getting this
> > right, I will create a documentation ticket.
>
> No, the structure hasn't changed. There should not be two levels of 'django'
> in that path. Why do you think there should be?
>
> 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-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.

Django development version docs

[Thomas B. Higgins]

I believe the directory structure for Django has changed. So, Writing
your first Django app, Part 1, 
http://docs.djangoproject.com/en/dev/intro/tutorial01/,
should refer to site-packages/django/django/bin, not site-packages/
django/bin as the path entry. If you all agree I am getting this
right, I will create a documentation 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-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: False negatives on model validation of CharField with choices

[Thomas B. Higgins]

Ramiro, great work on this! With your second patch I'm back in
business - with optgroups!

On a related matter, I don't often want a "blank" option when I use
choices/selects. I've been setting default selections and eliminating
the "blank" line as described on 11/07/07 by semenov in #4653 using a
combination of an explicit blank=False and a declared default value.
Under 1.1.1, this worked even when the field was disabled by
JavaScript (disabled because it was only conditionally required). I
had assumed that the default value was sent along to the database, but
don't really care. There was a big debate over what the convention for
"no blank choice" should be in #4653.

Now, using the development version, I can say blank=True, define a
default and get no blank option for some fields, while with other
fields with the same, identical model attribute structure yields a
select with the blank option. The only difference being that the
former group have "choices=something, required=False" in the model
form. Is the new convention that required=False in the model form
means no blank choice? This is wholly illogical to me.

Do you think this is an oversight? Is this new state of affairs
documented somewhere? Do you think it warrants a ticket?

Thanks for all your help.

Tom

On Jan 29, 5:13 am, Ramiro Morales  wrote:
> On Thu, Jan 28, 2010 at 2:46 PM, Thomas B.Higgins
>
>  wrote:
> > I've done some further checking, and see that this issue has two
> > parts. The first part is certainly a bug. Basically, selects with
> > optgroups are broken. Here's the 
> > ticket:http://code.djangoproject.com/ticket/12722.
>
> Sorry I didn't reply before, I had been offline.
>
> This has been already reported in ticket [1]12667. Please test the
> patch attached to
> it and report back your experiences.
>
> Regards,
>
> 1.http://code.djangoproject.com/ticket/12667
>
> --
> Ramiro Morales  |  http://rmorales.net

-- 
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: False negatives on model validation of CharField with choices

[Thomas B. Higgins]

Ramiro, great work on this! With your second patch I'm back in
business - with optgroups!

On a related matter, I don't often want a "blank" option when I use
choices/selects. I've been setting default selections and eliminating
the "blank" line as described on 11/07/07 by semenov in #4653 using a
combination of an explicit blank=False and a declared default value.
Under 1.1.1, this worked even when the field was disabled by
JavaScript (disabled because it was only conditionally required). I
had assumed that the default value was sent along to the database, but
don't really care. There was a big debate over what the convention for
"no blank choice" should be in #4653.

Now, using the development version, I can say blank=True, define a
default and get no blank option for some fields, while with other
fields with the same, identical model attribute structure yields a
select with the blank option. The only difference being that the
former group have "choices=something, required=False" in the model
form. Is the new convention that required=False in the model form
means no blank choice? This is wholly illogical to me.

Do you think this is an oversight? Is this new state of affairs
documented somewhere? Do you think it warrants a ticket?

Thanks for all your help.

Tom

On Jan 29, 5:13 am, Ramiro Morales  wrote:
> On Thu, Jan 28, 2010 at 2:46 PM, Thomas B.Higgins
>
>  wrote:
> > I've done some further checking, and see that this issue has two
> > parts. The first part is certainly a bug. Basically, selects with
> > optgroups are broken. Here's the 
> > ticket:http://code.djangoproject.com/ticket/12722.
>
> Sorry I didn't reply before, I had been offline.
>
> This has been already reported in ticket [1]12667. Please test the
> patch attached to
> it and report back your experiences.
>
> Regards,
>
> 1.http://code.djangoproject.com/ticket/12667
>
> --
> Ramiro Morales  |  http://rmorales.net

-- 
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: False negatives on model validation of CharField with choices

[Thomas B. Higgins]

I've done some further checking, and see that this issue has two
parts. The first part is certainly a bug. Basically, selects with
optgroups are broken. Here's the ticket: 
http://code.djangoproject.com/ticket/12722.

The second part is that if, on a choice field, blank=False, the model
won't validate unless there is a selection, even if a default is
supplied. So, if the field has been disabled, there will be an error.
This is different from previous Django behavior, but probably doesn't
matter much to me, now that I know what is happening.

On Jan 27, 10:44 pm, "Thomas B. Higgins" <thomasbhigg...@gmail.com>
wrote:
> I am writing to see if anyone thinks this is not a bug before creating
> a new ticket. I have an app that runs as expected on Django 1.1.1. It
> used to work on the development version, but a problem arose no later
> than 1.2 alpha 1 SVN-12271, and perhaps much earlier.
>
> Basically, the errors dictionary is wrong for every CharField with
> choices in the model. My custom validation continues to work, except
> when overridden by default validation. When my custom validation is
> commented out, the picture becomes clearer:
>
> 1)  An error "Value u"A325" is not a valid choice" is reported for a
> select field with no possibility of selecting a blank when any of the
> four available choices is selected. Elimination of the "blank" line is
> handled as described on 11/07/07 by semenov 
> athttp://code.djangoproject.com/ticket/4653
> using a combination of an explicit blank=False and a declared default
> value. This is baffling. I cannot conceive of a reason for an error in
> this case.
>
> 2) An error of "This field cannot be blank" is reported for fields
> with a default named in the model, such as:
>
> stiff_pl_grade    = models.CharField(max_length=8, choices=PL_grades,
> blank=False, default="A36",
>     help_text="Stiffener PL grade")
>
> It is my understanding that if a default is supplied, it should not be
> necessary to fill the field, even if blank=False.
>
> FloatFields with choices and IntegerFields with choices continue to
> behave as expected.
>
> It seems clear that when the is_valid() method is run on the form,
> something bad is happening to CharFields with choices, and this type
> of field only, and perfectly valid string selections or string
> defaults are being reported as invalid, probably by automatic model
> validation.
>
> My code works fine under version 1.1.1 and I see nothing in the
> development documentation to explain this odd new behavior.
>
> Any thoughts?

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

False negatives on model validation of CharField with choices

[Thomas B. Higgins]

I am writing to see if anyone thinks this is not a bug before creating
a new ticket. I have an app that runs as expected on Django 1.1.1. It
used to work on the development version, but a problem arose no later
than 1.2 alpha 1 SVN-12271, and perhaps much earlier.

Basically, the errors dictionary is wrong for every CharField with
choices in the model. My custom validation continues to work, except
when overridden by default validation. When my custom validation is
commented out, the picture becomes clearer:

1)  An error "Value u"A325" is not a valid choice" is reported for a
select field with no possibility of selecting a blank when any of the
four available choices is selected. Elimination of the "blank" line is
handled as described on 11/07/07 by semenov at 
http://code.djangoproject.com/ticket/4653
using a combination of an explicit blank=False and a declared default
value. This is baffling. I cannot conceive of a reason for an error in
this case.

2) An error of "This field cannot be blank" is reported for fields
with a default named in the model, such as:

stiff_pl_grade= models.CharField(max_length=8, choices=PL_grades,
blank=False, default="A36",
help_text="Stiffener PL grade")

It is my understanding that if a default is supplied, it should not be
necessary to fill the field, even if blank=False.

FloatFields with choices and IntegerFields with choices continue to
behave as expected.

It seems clear that when the is_valid() method is run on the form,
something bad is happening to CharFields with choices, and this type
of field only, and perfectly valid string selections or string
defaults are being reported as invalid, probably by automatic model
validation.

My code works fine under version 1.1.1 and I see nothing in the
development documentation to explain this odd new behavior.

Any thoughts?

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

I've lost my way and need help!

[Thomas B. Higgins]

I have been developing a Django web application using the development
root. It had been a while since I updated and, when I recently did (to
version 1.2 alpha 1 SVN-12271) it was clear something fairly basic had
gone awry. My application works fine under Version 1.1.1, but with the
development root, my form attributes seem to be out of sequence. For
example, on some choice fields where no bad choices are possible, I'm
getting errors like "Value u'F1852' is not a valid choice." Well,
"F1852" is valid, in fact.

In the Django 1.2 alpha 1 release notes, 
http://docs.djangoproject.com/en/dev/releases/1.2-alpha-1/,
I found reference to changes in __dict__ on Model instances. It says
"If your code relies on iterating over __dict__ to obtain a list of
fields, you must now filter the _state attribute of out __dict__."
Well, my code doesn't do this, at least not explicitly, but I do have
a peculiar bit of code that iterates through a ModelForm and makes a
list of dictionaries that gets sliced into segments which are then
passed to a template by a render_to_response statement. Here's the
code for this agglomerated object:

def combine_parameters_list_and_form(ParamList, ToolModelForm):
parameters_plus_form = []
r = range(0, len(ParamList))
I = iter(ToolModelForm)

for i in r:
parameters_plus_form.append({'paramlist': ParamList[i],
'widget': I.next()})

return parameters_plus_form

Is this causing my problem? Any other ideas?

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

syncdb fails to update Not NULL property in PostgreSQL 8.4

[Thomas B. Higgins]

Using the SVN trunk version of Django, I have observed that if a model
IntegerField or FloatField is changed by adding "null=True" syncdb
does not update the Not NULL property of the column using PostgeSQL
8.4. Is this correct behavior, or a bug? The two easy workarounds are
(1) drop the table using pgAdmin III and follow with a syncdb creating
a new table which will have the correct Not NULL status, or (2)
manually change the Not Null property value for the column using
pgAdmin III. Obviously the first method is a bit extreme.

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