date:20081115

[Django] #9609: (Null)BooleanField does not clean data correctly for MySQL with all widgets

2008-11-15 Thread Django

#9609: (Null)BooleanField does not clean data correctly for MySQL with all 
widgets
---+
 Reporter:  psagers|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 MySQL represents boolean values as 0 and 1, as the BooleanField
 documentation warns. This is not an issue when using a NullBooleanSelect
 widget, as NullBooleanSelect translates between model values and arbitrary
 integers for use in a form. However, not all choice widgets do this and
 thus they rely on the model values matching the widget values in order to
 populate initial widget state for rendering. The form field, in turn, must
 be able to clean the resulting form values. In order to support MySQL,
 therefore, (Null)BooleanField must understand '0' and '1'.

 Ticket 7753 added support for using HiddenWidget with the boolean fields,
 which addresses the general problem of cleaning raw form values. The
 attached patch adds '0' and '1' to the list of recognized values.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3357: Make Django's server optionally multithreaded

2008-11-15 Thread Django

#3357: Make Django's server optionally multithreaded
+---
  Reporter:  [EMAIL PROTECTED] | Owner:  adrian
Status:  reopened   | Milestone:
 Component:  django-admin.py runserver  |   Version:  SVN   
Resolution: |  Keywords:  post10
 Stage:  Design decision needed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by ubernostrum):

  * stage:  Accepted => Design decision needed

Comment:

 Something that's been wontfix'd twice by one of Django's lead devs sure as
 heck isn't "Accepted".

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9492: Invalid XHTML in admin/base.html template

2008-11-15 Thread Django

#9492: Invalid XHTML in admin/base.html template
---+
  Reporter:  dc| Owner:  wilson
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * owner:  nobody => wilson
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Wilson: did you just make a typo and leave off the "--" parts, or is this
 yet more MS funkiness and the conditional style syntax changed? In any
 case, it's your baby.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9345: Various string consistency fixes

2008-11-15 Thread Django

#9345: Various string consistency fixes
+---
  Reporter:  Semmel | Owner:  jezdez
Status:  assigned   | Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by mtredinnick):

 @jezdez: why is this assigned to you? Are you doing more work on it, or is
 there something else to look at?

 Not rushing you if there's something you want to do, but I'm wondering if
 there's something left to do beyond proof-read and check in.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9593: permalink breaks when using include() in urls.py

2008-11-15 Thread Django

#9593: permalink breaks when using include() in urls.py
+---
  Reporter:  IanLewis   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => invalid
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 The only bug here is in the URL pattern you've created. You're capturing
 everything from `blogs/` to the end of the string at the top level, so
 nothing will be seen by the second-level URLConf. Leave off the `(.*)`
 part and you'll find things work a lot better.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9585: r9398 broke test suite on Python2.3/2.4

2008-11-15 Thread Django

#9585: r9398 broke test suite on Python2.3/2.4
+---
  Reporter:  kmtracey   | Owner:  nobody
Status:  new| Milestone:
 Component:  Testing framework  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

  * stage:  Unreviewed => Ready for checkin

Comment:

 This is the right fix. The return result is intended to be treated like a
 tuple (partly precisely for backwards-compatibility with earlier Python
 code). I would prefer to use "4" instead of "-2" for the query access,
 though, since then you're not relying on the length of the tuple (and "4"
 is the documented value).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9598: create_user should allow specifying more fields

2008-11-15 Thread Django

#9598: create_user should allow specifying more fields
-+--
  Reporter:  [EMAIL PROTECTED]  | Owner:  nobody
Status:  new | Milestone:
 Component:  Authentication  |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by mtredinnick):

  * stage:  Unreviewed => Design decision needed

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9604: a patch to the docs regarding "how a complete example form could look like"

2008-11-15 Thread Django

#9604: a patch to the docs regarding "how a complete example form could look 
like"
---+
  Reporter:  vak <[EMAIL PROTECTED]>  | Owner:  nobody   
Status:  new   | Milestone:   
 Component:  django.contrib.comments   |   Version:  SVN  
Resolution:|  Keywords:  doc patch
 Stage:  Accepted  | Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * needs_better_patch:  => 0
  * has_patch:  1 => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 If somebody wants to make a patch for something like this, it would be a
 start.

 Note, however, that there's no need to include CSS in the example. There's
 nothing Django-specific about that and, in the above example, it's all up
 to whomever writes the template. However, the documentation for comments
 could mention any specific CSS classes that the template tags create (if
 there are any).

 Also, the example template fragment isn't correct, since there shouldn't
 be two controls for separate purposes with the same "name" attribute (it's
 broken for internationalisation purposes). The template fragments in the
 comments application show the correct approach.

 (I don't know why "has patch" has been checked here, since there's no
 patch attached.)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9605: form.save() exceptions should be more informative

2008-11-15 Thread Django

#9605: form.save() exceptions should be more informative
-+--
  Reporter:  [EMAIL PROTECTED]  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Uncategorized   |   Version:  1.0   
Resolution:  wontfix |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by mtredinnick):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 This isn't worth it -- it provides more than one way to do something. The
 errors are already available on the form instance at that moment (via
 `self.errors`) and if you want to throw away the form before checking the
 exception, you have to handle it yourself. Subclassing !ModelForm and
 providing a wrapper that raises the exception you want seems like one
 solution there.

 All your explanation of how POST and GET, etc, should be done is very
 normal and not relevant here. The only piece that seems relevant is that
 you don't access the form instance (it's difficult to tell from your
 example where the form handling is done, since it's all in the
 decorators). Since it's easy enough to do so (whatever one of your
 decorators is handling the form can take care of that), Django doesn't
 need a change to accommodate this.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #689: Honor Web server provided authentication

2008-11-15 Thread Django

#689: Honor Web server provided authentication
+---
  Reporter:  [EMAIL PROTECTED]| Owner:  telenieko
Status:  assigned   | Milestone:   
 Component:  Core framework |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Ready for checkin  | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Old description:

> I would like to see a 2nd mod_python handler. one which takes the
> REMOTE_USER parameter passed to it and for it to use that as the user-id
> so that I can hook my app into the default intranet security system we
> use over here.
>
> here is the patch to the original to make that the case.
>
> NOTE: it creates a user-record if none exist for the user.
>
> Helios:/src/django_newadmin/django/core/handlers ianh$ diff
> modpython_apacheauth.py modpython.py
> 102,103c102
> < #user_id = self.session[users.SESSION_KEY]
> < user_id = self._req.user
> ---
> > user_id = self.session[users.SESSION_KEY]
> 106,117c105,106
> < try:
> < self._user =
> users.get_object(username__exact=user_id)
> < except (users.UserDoesNotExist):
> < from django.models.auth import User
> < import md5
> < import datetime
> < password_md5 = md5.new('fake').hexdigest()
> < now = datetime.datetime.now()
> < self._user = User(None, user_id,'','',
> user_id+'@cnet.com',password_md5,False,True,False,now,now)
> < self._user.save()
> < #except (AttributeError, KeyError, ValueError,
> users.UserDoesNotExist):
> < except (AttributeError, KeyError, ValueError):
> ---
> > self._user = users.get_object(pk=user_id)
> > except (AttributeError, KeyError, ValueError,
> users.UserDoesNotExist):
> 120d108
> <

New description:

 I would like to see a 2nd mod_python handler. one which takes the
 REMOTE_USER parameter passed to it and for it to use that as the user-id
 so that I can hook my app into the default intranet security system we use
 over here.

 here is the patch to the original to make that the case.

 NOTE: it creates a user-record if none exist for the user.

 {{{
 Helios:/src/django_newadmin/django/core/handlers ianh$ diff
 modpython_apacheauth.py modpython.py
 102,103c102
 < #user_id = self.session[users.SESSION_KEY]
 < user_id = self._req.user
 ---
 > user_id = self.session[users.SESSION_KEY]
 106,117c105,106
 < try:
 < self._user =
 users.get_object(username__exact=user_id)
 < except (users.UserDoesNotExist):
 < from django.models.auth import User
 < import md5
 < import datetime
 < password_md5 = md5.new('fake').hexdigest()
 < now = datetime.datetime.now()
 < self._user = User(None, user_id,'','',
 user_id+'@cnet.com',password_md5,False,True,False,now,now)
 < self._user.save()
 < #except (AttributeError, KeyError, ValueError,
 users.UserDoesNotExist):
 < except (AttributeError, KeyError, ValueError):
 ---
 > self._user = users.get_object(pk=user_id)
 > except (AttributeError, KeyError, ValueError,
 users.UserDoesNotExist):
 120d108
 <
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9608: Broken model unicode methods can lead to bare exceptions

2008-11-15 Thread Django

#9608: Broken model unicode methods can lead to bare exceptions
-+--
  Reporter:  kmtracey| Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by mtredinnick):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * component:  Uncategorized => Core framework
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 I wouldn't want to diguise this error too much, but you're right about
 bullet-proofing the debug page. Making repr() immune to the problem sounds
 like a good fix, since that will help with interactive debugging as well.
 Catching unicode encode errors and replacing it with something like "[Bad
 Unicode data]" would work for me.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9606: link to django packages for openSUSE

2008-11-15 Thread Django

#9606: link to django packages for openSUSE
+---
  Reporter:  poeml  | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by kmtracey):

 What I think may make more sense than adding more very specific
 availability notes for distributions is to revamp that page to provide
 more general pointers to how to find out whether your distribution has a
 packaged release of interest to you.  For example, for Ubuntu such a link
 would be:

 http://packages.ubuntu.com/search?searchon=names&keywords=django

 I have no idea whether other distribs have such pages, though, and not
 much interest in researching it myself.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9606: link to django packages for openSUSE

2008-11-15 Thread Django

#9606: link to django packages for openSUSE
+---
  Reporter:  poeml  | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by Alex):

 Yep, debian stable is still .95, ubuntu is up to 1.0 though.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9464 - django/trunk/django/contrib/admin/templates/admin/auth/user

2008-11-15 Thread noreply


Author: wilson
Date: 2008-11-15 18:09:39 -0600 (Sat, 15 Nov 2008)
New Revision: 9464

Modified:
   
django/trunk/django/contrib/admin/templates/admin/auth/user/change_password.html
Log:
Updated stylesheet link on the change password form.

Modified: 
django/trunk/django/contrib/admin/templates/admin/auth/user/change_password.html
===
--- 
django/trunk/django/contrib/admin/templates/admin/auth/user/change_password.html
2008-11-16 00:08:48 UTC (rev 9463)
+++ 
django/trunk/django/contrib/admin/templates/admin/auth/user/change_password.html
2008-11-16 00:09:39 UTC (rev 9464)
@@ -3,7 +3,7 @@
 {% block extrahead %}{{ block.super }}
 
 {% endblock %}
-{% block stylesheet %}{% admin_media_prefix %}css/forms.css{% endblock %}
+{% block extrastyle %}{% endblock %}
 {% block bodyclass %}{{ opts.app_label }}-{{ opts.object_name.lower }} 
change-form{% endblock %}
 {% block breadcrumbs %}{% if not is_popup %}
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9463 - in django/trunk/django/contrib/admin: media/css templates/admin

2008-11-15 Thread noreply


Author: wilson
Date: 2008-11-15 18:08:48 -0600 (Sat, 15 Nov 2008)
New Revision: 9463

Modified:
   django/trunk/django/contrib/admin/media/css/changelists.css
   django/trunk/django/contrib/admin/media/css/dashboard.css
   django/trunk/django/contrib/admin/media/css/forms.css
   django/trunk/django/contrib/admin/media/css/login.css
   django/trunk/django/contrib/admin/templates/admin/base.html
   django/trunk/django/contrib/admin/templates/admin/change_form.html
   django/trunk/django/contrib/admin/templates/admin/change_list.html
   django/trunk/django/contrib/admin/templates/admin/index.html
   django/trunk/django/contrib/admin/templates/admin/login.html
Log:
Removed the hidden import rules in the contrib.admin stylesheets. Each 
individual stylesheet is now linked to explicitly from the template where it's 
used (in the extrastyle block), with the exception of widgets.css, which is 
imported by forms.css, but still available separately for reuse. Also moved the 
override stylesheets (IE and RTL) below the extrastyle block and all styles 
within the conditional comment which blocks CSS from IE5 and lower.

Modified: django/trunk/django/contrib/admin/media/css/changelists.css
===
--- django/trunk/django/contrib/admin/media/css/changelists.css 2008-11-15 
12:31:36 UTC (rev 9462)
+++ django/trunk/django/contrib/admin/media/css/changelists.css 2008-11-16 
00:08:48 UTC (rev 9463)
@@ -1,5 +1,3 @@
[EMAIL PROTECTED] url('base.css');
-
 /* CHANGELISTS */
 
 #changelist {

Modified: django/trunk/django/contrib/admin/media/css/dashboard.css
===
--- django/trunk/django/contrib/admin/media/css/dashboard.css   2008-11-15 
12:31:36 UTC (rev 9462)
+++ django/trunk/django/contrib/admin/media/css/dashboard.css   2008-11-16 
00:08:48 UTC (rev 9463)
@@ -1,5 +1,3 @@
[EMAIL PROTECTED] url('base.css');
-
 /* DASHBOARD */
 
 .dashboard .module table th {

Modified: django/trunk/django/contrib/admin/media/css/forms.css
===
--- django/trunk/django/contrib/admin/media/css/forms.css   2008-11-15 
12:31:36 UTC (rev 9462)
+++ django/trunk/django/contrib/admin/media/css/forms.css   2008-11-16 
00:08:48 UTC (rev 9463)
@@ -1,4 +1,3 @@
[EMAIL PROTECTED] url('base.css');
 @import url('widgets.css');
 
 /* FORM ROWS */

Modified: django/trunk/django/contrib/admin/media/css/login.css
===
--- django/trunk/django/contrib/admin/media/css/login.css   2008-11-15 
12:31:36 UTC (rev 9462)
+++ django/trunk/django/contrib/admin/media/css/login.css   2008-11-16 
00:08:48 UTC (rev 9463)
@@ -1,5 +1,3 @@
[EMAIL PROTECTED] url('base.css');
-
 /* LOGIN FORM */
 
 body.login {

Modified: django/trunk/django/contrib/admin/templates/admin/base.html
===
--- django/trunk/django/contrib/admin/templates/admin/base.html 2008-11-15 
12:31:36 UTC (rev 9462)
+++ django/trunk/django/contrib/admin/templates/admin/base.html 2008-11-16 
00:08:48 UTC (rev 9463)
@@ -2,10 +2,12 @@
 http://www.w3.org/1999/xhtml"; lang="{{ LANGUAGE_CODE }}" 
xml:lang="{{ LANGUAGE_CODE }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif %}>
 
 {% block title %}{% endblock %}
-
+
+
+{% block extrastyle %}{% endblock %}
 
 {% if LANGUAGE_BIDI %}{% endif 
%}
-{% block extrastyle %}{% endblock %}
+
 {% block extrahead %}{% endblock %}
 {% block blockbots %}{% 
endblock %}
 

Modified: django/trunk/django/contrib/admin/templates/admin/change_form.html
===
--- django/trunk/django/contrib/admin/templates/admin/change_form.html  
2008-11-15 12:31:36 UTC (rev 9462)
+++ django/trunk/django/contrib/admin/templates/admin/change_form.html  
2008-11-16 00:08:48 UTC (rev 9463)
@@ -6,7 +6,7 @@
 {{ media }}
 {% endblock %}
 
-{% block stylesheet %}{% admin_media_prefix %}css/forms.css{% endblock %}
+{% block extrastyle %}{% endblock %}
 
 {% block coltype %}{% if ordered_objects %}colMS{% else %}colM{% endif %}{% 
endblock %}
 

Modified: django/trunk/django/contrib/admin/templates/admin/change_list.html
===
--- django/trunk/django/contrib/admin/templates/admin/change_list.html  
2008-11-15 12:31:36 UTC (rev 9462)
+++ django/trunk/django/contrib/admin/templates/admin/change_list.html  
2008-11-16 00:08:48 UTC (rev 9463)
@@ -1,7 +1,7 @@
 {% extends "admin/base_site.html" %}
 {% load adminmedia admin_list i18n %}
 
-{% block stylesheet %}{% admin_media_prefix %}css/changelists.css{% endblock %}
+{% block extrastyle %}{% endblock %}
 
 {% block bodyclass %}change-list{% endblock %}
 

Modified: django/trunk/django/contrib/admin/templates/admin/index.html
===
--- django/trunk/django/contrib/admin/templ

Re: [Django] #9606: link to django packages for openSUSE

2008-11-15 Thread Django

#9606: link to django packages for openSUSE
+---
  Reporter:  poeml  | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by kmtracey):

 Specifically on this page:
 http://docs.djangoproject.com/en/dev/misc/distributions/#misc-
 distributions

 there are instruction for Debian, Fedora, Gentoo, and Ubuntu flavors of
 Linux, so I can see where this idea came from.  However, I have no idea
 how up-to-date that page is (is 0.95.1 still what you get in Debian
 'stable'?).I tend to think we might want to scale back on such
 distrib-specific notes, because I don't think we can reliably keep them
 up-to-date.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9608: Broken model unicode methods can lead to bare exceptions

2008-11-15 Thread Django

#9608: Broken model unicode methods can lead to bare exceptions
---+
 Reporter:  kmtracey   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Given this model registerd with the admin:

 {{{
 # -*- coding: utf-8 -*-
 from django.db import models

 class BrokenUnicodeMethod(models.Model):
 name = models.CharField(max_length=6)
 def __unicode__(self):
 return 'Názov: %s' % self.name

 }}}

 attempting to add one in the admin (with DEBUG set to True) generates a
 bare traceback:

 {{{
 Traceback (most recent call last):

   File "/home/kmt/django/trunk/django/core/servers/basehttp.py", line 278,
 in run
 self.result = application(self.environ, self.start_response)

   File "/home/kmt/django/trunk/django/core/servers/basehttp.py", line 635,
 in __call__
 return self.application(environ, start_response)

   File "/home/kmt/django/trunk/django/core/handlers/wsgi.py", line 239, in
 __call__
 response = self.get_response(request)

   File "/home/kmt/django/trunk/django/core/handlers/base.py", line 128, in
 get_response
 return self.handle_uncaught_exception(request, resolver, exc_info)

   File "/home/kmt/django/trunk/django/core/handlers/base.py", line 148, in
 handle_uncaught_exception
 return debug.technical_500_response(request, *exc_info)

   File "/home/kmt/django/trunk/django/views/debug.py", line 39, in
 technical_500_response
 html = reporter.get_traceback_html()

   File "/home/kmt/django/trunk/django/views/debug.py", line 97, in
 get_traceback_html
 'exception_value': smart_unicode(self.exc_value, errors='replace'),

   File "/home/kmt/django/trunk/django/utils/encoding.py", line 35, in
 smart_unicode
 return force_unicode(s, encoding, strings_only, errors)

   File "/home/kmt/django/trunk/django/utils/encoding.py", line 70, in
 force_unicode
 raise DjangoUnicodeDecodeError(s, *e.args)

 DjangoUnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
 1: ordinal not in range(128). You passed in
 DjangoUnicodeDecodeError('ascii', 'N\xc3\xa1zov: ', 1, 2, 'ordinal not in
 range(128)') ()

 }}}

 The original !DjanoUnicodeDecodeError comes from the admin trying a
 force_unicode on the new object for the log message.  That gets caught and
 `get_traceback_html` attempts to calls `smart_unicode` on the exception
 value, which ultimately calls the `__str__` method for
 !DjangoUnicodeDecodeError:

 {{{
 def __str__(self):
 original = UnicodeDecodeError.__str__(self)
 return '%s. You passed in %r (%s)' % (original, self.obj,
 type(self.obj))
 }}}

 `self.obj` is the origin object where `__unicode__` generated an
 exception.  But the attempt to use its repr is going to call unicode on it
 again, since `__repr__` for an model is (from django/db/models/base.py):

 {{{
 def __repr__(self):
 return smart_str(u'<%s: %s>' % (self.__class__.__name__,
 unicode(self)))
 }}}

 and we get another !UnicodeDecodeException.

 Of course the model's `__unicode__` method is broken, returning non-ASCII
 data in a bytestring instead of a unicode object, but Django shouldn't
 obscure that error by generating an error itself trying to say that.
 Specifically I think the model `__repr__` ought to guard against
 `unicode(self)` generating an exception and substitute placeholder text if
 that happens, but I'm not entirely sure of that so I didn't just do it.
 Other opinions?

 The original problem was reported in this thread:
 http://groups.google.com/group/django-
 users/browse_thread/thread/4209cc8f669f5e12

 and involved a `__unicode__` method that looked like this:

 {{{
 def __unicode__(self):
 return "%s %s" % (self.vrstva, self.nazov)
 }}}

 Here 'vrstva' is a foreign key, with a valid `__unicode__` method that was
 returning non-ASCII data, converted to a utf-8 bytestring by the default
 Model `__str__` method:

 {{{
 def __str__(self):
 if hasattr(self, '__unicode__'):
 return force_unicode(self).encode('utf-8')
 return '%s object' % self.__class__.__name__
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9606: link to django packages for openSUSE

2008-11-15 Thread Django

#9606: link to django packages for openSUSE
+---
  Reporter:  poeml  | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * status:  closed => reopened
  * resolution:  wontfix =>
  * stage:  Unreviewed => Accepted

Comment:

 I'm reopening this, the docs have links to the packages for plenty of
 other distros.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9606: link to django packages for openSUSE

2008-11-15 Thread Django

#9606: link to django packages for openSUSE
+---
  Reporter:  poeml  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution:  wontfix|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => wontfix
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 I think this is too specific for for the Django website. There are so many
 Linux distributions that have Django packages in their package
 repositories. So if this is added to the download page, you need to add
 links to Debian packages for example, too. Anyway these packages are not
 up-to-date most time.

 And if you really want to install Django using the package manager of your
 distribution, you can search for the package name yourself (for example
 `apt-cache search django` on debian-based systems).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #2306: Many-to-many queries very slow on MySQL 3.23.58

2008-11-15 Thread Django

#2306: Many-to-many queries very slow on MySQL 3.23.58
---+
  Reporter:  anonymous | Owner:  nobody 
Status:  closed| Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:  fixed |  Keywords:  qs-rf-fixed
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by pjorstad):

 go now for female bodybuilding videos at great prices

 [http://www.bodybuilding-videos.net/ female bodybuilding videos]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9607: Add documentation for **extra parameter to test client request methods

2008-11-15 Thread Django

#9607: Add documentation for **extra parameter to test client request methods
-+--
 Reporter:  jroes|   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Documentation| Version:  SVN   
 Keywords:  test client headers  |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 The **extra parameter in the request methods for the Django test client
 provides the user with the ability to send HTTP headers.  This parameter
 wasn't covered in the existing docs in SVN r9462.

 I'm not sure what version this was added in or if it has been there all
 along, so I wasn't able to identify that in my patch.  Maybe someone
 seeing this ticket will know.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9606: link to django packages for openSUSE

2008-11-15 Thread Django

#9606: link to django packages for openSUSE
---+
 Reporter:  poeml  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Here's a text:

 {{{


 A Django package is available for http://www.opensuse.org/"openSUSE Linux in the http://build.opensuse.org/";>openSUSE Build Service, and is based
 on Django 1.0.1.

 The current package can be installed by subscribing to the
 devel:languages:python project from http://download.opensuse.org/repositories/devel:/languages:/python/";>here
 and typing 'zypper install python-django'.

 Alternatively, you can use one-click-install link at http://software.opensuse.org/search?q=python-
 django">http://software.opensuse.org/search?q=python-djangohttp://code.djangoproject.com/ticket/9606>
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3501: [patch] sqlite selection on datetime members fail when datefield is null

2008-11-15 Thread Django

#3501: [patch] sqlite selection on datetime members fail when datefield is null
---+
  Reporter:  anonymous | Owner:  baumer1122
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:  sqlite
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Comment (by mrts):

 Indeed, using `date__month` causes the error.

 Given
 {{{
 $ cat datefield_null/models.py
 from django.db import models

 class DateStamp(models.Model):
 date = models.DateField(blank=True, null=True)

 $ grep DATABASE settings.py
 DATABASE_ENGINE = 'sqlite3'   # 'postgresql_psycopg2',
 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
 DATABASE_NAME = os.path.join(PROJDIR, 'test.db') # Or path to
 database file if using sqlite3.
 DATABASE_USER = '' # 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.

 $ python -c 'import sqlite3; print sqlite3.dbapi2.sqlite_version_info'
 (3, 5, 9)

 $ python -c 'import django; print django.get_version()'
 1.0.2 pre-alpha SVN-9462

 $ cat /etc/lsb-release
 DISTRIB_ID=Ubuntu
 DISTRIB_RELEASE=8.10
 DISTRIB_CODENAME=intrepid
 DISTRIB_DESCRIPTION="Ubuntu 8.10"
 }}}

 the following occurs:

 {{{
 >>> from bug3501.datefield_null.models import DateStamp
 >>> import datetime
 >>> d = DateStamp(date=None)
 >>> d.save()
 >>> d = DateStamp(date=datetime.date.today())
 >>> d.save()
 >>> DateStamp.objects.filter(date__year=2008)
 [, ]
 >>> DateStamp.objects.filter(date__month=2)
 Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib/python2.5/site-packages/django/db/models/query.py", line
 147, in __repr__
 data = list(self[:REPR_OUTPUT_SIZE + 1])
   File "/usr/lib/python2.5/site-packages/django/db/models/query.py", line
 162, in __len__
 self._result_cache.extend(list(self._iter))
   File "/usr/lib/python2.5/site-packages/django/db/models/query.py", line
 275, in iterator
 for row in self.query.results_iter():
   File "/usr/lib/python2.5/site-packages/django/db/models/sql/query.py",
 line 206, in results_iter
 for rows in self.execute_sql(MULTI):
   File "/usr/lib/python2.5/site-packages/django/db/models/sql/query.py",
 line 1734, in execute_sql
 cursor.execute(sql, params)
   File "/usr/lib/python2.5/site-packages/django/db/backends/util.py", line
 19, in execute
 return self.cursor.execute(sql, params)
   File "/usr/lib/python2.5/site-
 packages/django/db/backends/sqlite3/base.py", line 168, in execute
 return Database.Cursor.execute(self, query, params)
 OperationalError: user-defined function raised exception
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8167: Allow custom message to be set in the create/update/delete generic views

2008-11-15 Thread Django

#8167: Allow custom message to be set in the create/update/delete generic views
+---
  Reporter:  peterd12   | Owner:  ColtonProvias
Status:  assigned   | Milestone:  post-1.0 
 Component:  Generic views  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by ColtonProvias):

  * owner:  nobody => ColtonProvias
  * status:  new => assigned
  * stage:  Design decision needed => Accepted

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3501: [patch] sqlite selection on datetime members fail when datefield is null

2008-11-15 Thread Django

#3501: [patch] sqlite selection on datetime members fail when datefield is null
---+
  Reporter:  anonymous | Owner:  baumer1122
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:  sqlite
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Comment (by jerry):

 I've got sqlite 3.4.0 on Mac OS X 10.5.5.
 {{{
 George:~ jerry$ python
 Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:16)
 [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import sqlite3
 >>> sqlite3.dbapi2.sqlite_version_info
 (3, 4, 0)
 >>>
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9605: form.save() exceptions should be more informative

2008-11-15 Thread Django

#9605: form.save() exceptions should be more informative
-+--
  Reporter:  [EMAIL PROTECTED]  | Owner:  nobody
Status:  new | Milestone:
 Component:  Uncategorized   |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by [EMAIL PROTECTED]):

 Okay, let me explain.

 First of all, it’s common practice not to return a page in response to a
 POST, but rather always redirect to GET. That’s to allow bookmarking of
 URLs and sensible behavior of the reload button. Following this principle,
 when a POST fails, I redirect back to the original form and also pass the
 variable with the error list to that view. In fact, all my POSTs are to
 the same URL (/submission). A typical POST handler looks like this:
 {{{
 @post_handler(action="property:delete") # 
 @access_restricted # require request.user.is_authenticated, handle
 access_denied exception
 @autoload_require_editable(models.property, pk="property_id") # fetches
 the object, can raise access_denied if not owned by request.user
 def do_delete_property(request, property):
 property.delete()
 return url_from_view(console_list) # this calls urlresolvers.reverse
 and returns a string
 }}}
 where the function can’t even return anything except a URL that will be
 then wrapped in an HttpResponseRedirect.

 

 What I ask for is merely:

 1. Create an exception class that can store form.errors;
 1. Raise it rather than ValueError;
 1. Not to break code that depends on current behavior.

 I mean, rather than
 {{{
 if form.errors:
 raise ValueError("The %s could not be %s because the data didn't"
  " validate." % (opts.object_name, fail_message))
 }}}
 have
 {{{
 class InvalidFormError(ValueError):
 ...

 if form.errors:
 raise InvalidFormError("..." % (...), form.errors)
 }}}
 That would help for use cases such as mine, and would not break anything
 for users that do not need such a functionality.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8167: Allow custom message to be set in the create/update/delete generic views

2008-11-15 Thread Django

#8167: Allow custom message to be set in the create/update/delete generic views
-+--
  Reporter:  peterd12| Owner:  nobody  
Status:  new | Milestone:  post-1.0
 Component:  Generic views   |   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by ColtonProvias):

  * has_patch:  0 => 1

Comment:

 I attempted to create a small patch to add on this functionality.  It
 processes the string passed to it as a template and renames model._meta to
 model.meta.  If something doesn't work, I apologize as this is my first
 attempt at a patch to django.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3501: [patch] sqlite selection on datetime members fail when datefield is null

2008-11-15 Thread Django

#3501: [patch] sqlite selection on datetime members fail when datefield is null
---+
  Reporter:  anonymous | Owner:  baumer1122
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:  sqlite
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 Whenever there are multiple reports of people saying "it's broken" and "it
 works for me" it helps if people identify not only the version of Django
 they are using, but the version of related software, in this case sqlite.
 So the output from:

 {{{
 >>> import sqlite3
 >>> sqlite3.dbapi2.sqlite_version_info
 }}}

 in a Python prompt could be useful.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3501: [patch] sqlite selection on datetime members fail when datefield is null

2008-11-15 Thread Django

#3501: [patch] sqlite selection on datetime members fail when datefield is null
---+
  Reporter:  anonymous | Owner:  baumer1122
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:  sqlite
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Comment (by jerry):

 Sorry about the formatting. This should have been:

 {{{
 The problem appears to be with .filter(date__month=x).
 Using 1.0.1 I can successfully perform the tests above on my own data,
 but when I try __month (without the above patch applied) I get:

 >>> Album.objects.filter(purchaseDate__month=3)
 Traceback (most recent call last):
   File "", line 1, in 
   File "/Library/Python/2.5/site-packages/django/db/models/query.py", line
 147, in __repr__
 data = list(self[:REPR_OUTPUT_SIZE + 1])
   File "/Library/Python/2.5/site-packages/django/db/models/query.py", line
 162, in __len__
 self._result_cache.extend(list(self._iter))
   File "/Library/Python/2.5/site-packages/django/db/models/query.py", line
 275, in iterator
 for row in self.query.results_iter():
   File "/Library/Python/2.5/site-packages/django/db/models/sql/query.py",
 line 206, in results_iter
 for rows in self.execute_sql(MULTI):
   File "/Library/Python/2.5/site-packages/django/db/models/sql/query.py",
 line 1734, in execute_sql
 cursor.execute(sql, params)
   File "/Library/Python/2.5/site-
 packages/django/db/backends/sqlite3/base.py", line 168, in execute
 return Database.Cursor.execute(self, query, params)
 OperationalError: user-defined function raised exception

 The same with __day; it fails as above; but applying the patch to
 _sqlite_extract,
 the errors go away and the filter works as expected. (And I can use the
 admin
 to focus on the date_hierarchy field.)
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9522: Python serializer doesn't use base Serializer.get_string_value

2008-11-15 Thread Django

#9522: Python serializer doesn't use base Serializer.get_string_value
+---
  Reporter:  alexkoshelev   | Owner:  nobody  
Status:  new| Milestone:  post-1.0
 Component:  Serialization  |   Version:  1.0 
Resolution: |  Keywords:  
 Stage:  Unreviewed | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

  * needs_better_patch:  1 => 0
  * needs_tests:  1 => 0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9605: form.save() exceptions should be more informative

2008-11-15 Thread Django

#9605: form.save() exceptions should be more informative
-+--
  Reporter:  [EMAIL PROTECTED]  | Owner:  nobody
Status:  new | Milestone:
 Component:  Uncategorized   |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by kmtracey):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Why are you trying to save a form before first verifying that it is valid?
 The normal pattern
 (http://docs.djangoproject.com/en/dev/topics/forms/#using-a-form-
 in-a-view) is to call is_valid yourself first and not proceed with an
 attempt to save if the form hasn't validated.  You seem to have come up
 with a different pattern (somewhat more complicated, involving storing
 errors in a session variable instead of just re-displaying the posted form
 with errors in place) and I don't understand why.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3501: [patch] sqlite selection on datetime members fail when datefield is null

2008-11-15 Thread Django

#3501: [patch] sqlite selection on datetime members fail when datefield is null
---+
  Reporter:  anonymous | Owner:  baumer1122
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:  sqlite
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Changes (by jerry):

  * status:  closed => reopened
  * resolution:  worksforme =>

Comment:

 The problem appears to be with .filter(date__month=x). Using 1.0.1 I can
 successfully perform the tests above on my own data, but when I try
 __month (without the above patch applied) I get:

 >>> Album.objects.filter(purchaseDate__month=3)
 Traceback (most recent call last):
   File "", line 1, in 
   File "/Library/Python/2.5/site-packages/django/db/models/query.py", line
 147, in __repr__
 data = list(self[:REPR_OUTPUT_SIZE + 1])
   File "/Library/Python/2.5/site-packages/django/db/models/query.py", line
 162, in __len__
 self._result_cache.extend(list(self._iter))
   File "/Library/Python/2.5/site-packages/django/db/models/query.py", line
 275, in iterator
 for row in self.query.results_iter():
   File "/Library/Python/2.5/site-packages/django/db/models/sql/query.py",
 line 206, in results_iter
 for rows in self.execute_sql(MULTI):
   File "/Library/Python/2.5/site-packages/django/db/models/sql/query.py",
 line 1734, in execute_sql
 cursor.execute(sql, params)
   File "/Library/Python/2.5/site-
 packages/django/db/backends/sqlite3/base.py", line 168, in execute
 return Database.Cursor.execute(self, query, params)
 OperationalError: user-defined function raised exception

 The same with __day; it fails as above; but applying the patch to
 _sqlite_extract, the errors go away and the filter works as expected. (And
 I can use the admin to focus on the date_hierarchy field.)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9605: form.save() exceptions should be more informative

2008-11-15 Thread Django

#9605: form.save() exceptions should be more informative
+---
 Reporter:  [EMAIL PROTECTED]  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Uncategorized   | Version:  1.0   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Currently form.save() raises a ValueError if !form.is_valid(). I suggest
 it should throw some exception from which form.errors could be extracted.

 I have this workaround:
 {{{
 def enforce_valid(form):
 if not form.is_valid():
 raise invalid_form(form.errors)
 return form

 ...
 enforce_valid(some_form(...)).save()
 ...
 }}}
 and also there’s code that catches the custom exception and puts the
 errors into a session variable and redirects back to the originating page
 and shows the errors there.

 Why does form.save() only provide a message that something went wrong and
 not the actual errors? It could raise an exception derived from ValueError
 that would contain the list of errors.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #4002: Attributes added by extra() aren't visible to filter()

2008-11-15 Thread Django

#4002: Attributes added by extra() aren't visible to filter()
---+
  Reporter:  [EMAIL PROTECTED]  | Owner:  nobody
  
Status:  closed| Milestone: 
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:  invalid   |  Keywords:  extra 
filter
 Stage:  Accepted  | Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by alsleme):

 [http://www.travelerpedia.net/ فنادق]
 [http://www.travelerpedia.net/africa/egypt/cairo/ القاهرة]
 [http://www.travelerpedia.net/photo/ صور فنادق]
 [http://www.travelerpedia.net/africa/egypt/sharm_el_sheikh/ فنادق شرم
 الشيخ]
 [http://www.travelerpedia.net/africa/egypt/alexandria/ الاسكندرية]
 [http://www.travelerpedia.net/africa/egypt/ مصر]
 [http://www.travelerpedia.net/africa/egypt/alexandria/ فنادق الاسكندرية]
 [http://www.travelerpedia.net/asia/uae/dubai/ دبي]
 [http://www.travelerpedia.net/asia/uae/dubai/ فنادق دبي]
 [http://www.travelerpedia.net/asia/uae/ فنادق الامارات]
 [http://www.travelerpedia.net/asia/malaysia/kuala-lumpur/ فنادق
 كوالالمبور]
 [http://www.travelerpedia.net/asia/malaysia/penang/ فنادق بينانج]
 [http://www.travelerpedia.net/asia/malaysia/ فنادق ماليزيا]
 [http://www.travelerpedia.net/asia/malaysia/langkawi/ فنادق لنكاوي]
 [http://www.travelerpedia.net/asia/turkey/istanbul/ فنادق اسطنبول]
 [http://www.travelerpedia.net/asia/turkey/ فنادق تركيا]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6972: Cheese shop entry for django is broken

2008-11-15 Thread Django

#6972: Cheese shop entry for django is broken
+---
  Reporter:  Ionel Maries <[EMAIL PROTECTED]>  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  SVN   
Resolution:  fixed  |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by ubernostrum):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 As of Django 1.0.1, `easy_install django` works. So does `pip install
 django` if you prefer pip.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9462 - django/branches/releases/1.0.X

2008-11-15 Thread noreply


Author: ubernostrum
Date: 2008-11-15 06:31:36 -0600 (Sat, 15 Nov 2008)
New Revision: 9462

Modified:
   django/branches/releases/1.0.X/setup.py
Log:
[1.0.X] Now that this branch is 1.0.2 pre-alpha, it shouldn't have a 
download_url set in the setup.py.


Modified: django/branches/releases/1.0.X/setup.py
===
--- django/branches/releases/1.0.X/setup.py 2008-11-15 06:28:20 UTC (rev 
9461)
+++ django/branches/releases/1.0.X/setup.py 2008-11-15 12:31:36 UTC (rev 
9462)
@@ -74,7 +74,6 @@
 name = "Django",
 version = version.replace(' ', '-'),
 url = 'http://www.djangoproject.com/',
-download_url = 
'http://media.djangoproject.com/releases/1.0.1/Django-1.0.1-final.tar.gz',
 author = 'Django Software Foundation',
 author_email = '[EMAIL PROTECTED]',
 description = 'A high-level Python Web framework that encourages rapid 
development and clean, pragmatic design.',


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9604: a patch to the docs regarding "how a complete example form could look like"

2008-11-15 Thread Django

#9604: a patch to the docs regarding "how a complete example form could look 
like"
--+-
 Reporter:  vak <[EMAIL PROTECTED]>  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.comments   | Version:  SVN   
 Keywords:  doc patch |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 there is an example of a complete form in the section "RENDERING A CUSTOM
 COMMENT FOR" on this page:
 http://docs.djangoproject.com/en/dev/ref/contrib/comments/

 it is not fully correct, because:

  1. the example results in a list of tr elements not surrounded by table
 element.
  2. the button below the form is a mess between "preview" and "post".

 the example might be like:

 {{{
 Post a comment
 {% get_comment_form for blog.entry 1 as form %}
 
 
   
 {{ form }}
 
   
   
 
 
   
 
   
 
 
 }}}

 and a few lines of the following stylesheet
 {{{
 
 #myform label[for="id_honeypot"], #myform input#id_honeypot {
   display:none
 }

 #myform table th, #myform #action_buttons {
   text-align:right
 }
 
 }}}

 will help to all newbies like I am.

 regards,
 Valer

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

37 matches

Mail list logo