date:20111010

Re: [Django] #12467: More helpful error message when loading fixture with invalid date

2011-10-10 Thread Django

#12467: More helpful error message when loading fixture with invalid date
--+
 Reporter:  knutin|Owner:  raulcd
 Type:  New feature   |   Status:  assigned
Component:  Core (Serialization)  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by julien):

 The patch looks good. While we're at it, we should also do the same for
 `DateField`'s "invalid_date" and `DateTimeField`'s "invalid" messages. See
 amended 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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #9995: Mention 'pip install Django' as an alternative installation method.

2011-10-10 Thread Django

#9995: Mention 'pip install Django' as an alternative installation method.
-+-
 Reporter:  daveyjoe |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Documentation|  Version:  1.0
 Severity:  Normal   |   Resolution:
 Keywords:  easy_install, docs,  | Triage Stage:  Accepted
  documentation, install,|  Needs documentation:  0
  installation, setup|  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by paulcollins):

 * cc: paul.collins.iii@… (added)


-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16307: Unable to expand (resolve) template variable attribute when the variable is a python class

2011-10-10 Thread Django

#16307: Unable to expand (resolve) template variable attribute when the 
variable is
a python class
-+
 Reporter:  sorin|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by lukeplant):

 This will, of course, break anyone who had a class like:
 {{{
 class Foo(object):
 def __init__(self):
 self.bar = 123
 }}}

 and then did 'Foo.bar' in a template with `{'Foo':Foo}` passed in as the
 context.

 Is that a silly thing to do? Well, that's debatable, but it has one
 massive thing in its favour: it is the status quo, and every change we've
 ever made in this section of code has generated 'regression' bug reports.

 The docs clearly state: "If any part of the variable is callable, the
 template system will try calling it", which is exactly what happens.
 Personally I'm finding it hard to see the bug here.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16307: Unable to expand (resolve) template variable attribute when the variable is a python class

2011-10-10 Thread Django

#16307: Unable to expand (resolve) template variable attribute when the 
variable is
a python class
-+
 Reporter:  sorin|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by rico):

 * cc: rico (added)
 * has_patch:  0 => 1


Comment:

 Added a patch with tests against the 1.3.1 tag of the official git
 repository on github.

 The tests covers accessing an attribute, a class method and a static
 method on a class.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12099: admindocs generates an error on the tags page when template tags are included in an egg file

2011-10-10 Thread Django

#12099: admindocs generates an error on the tags page when template tags are
included in an egg file
-+-
 Reporter:  Mark S. Choate   |Owner:  nobody
     |   Status:  new
 Type:  Bug  |  Version:  1.1
Component:  contrib.admindocs|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by ramiro):

 * ui_ux:   => 0
 * component:  contrib.admin => contrib.admindocs
 * easy:   => 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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17032: Tests for contrib.auth fail if login signals use templates

2011-10-10 Thread Django

#17032: Tests for contrib.auth fail if login signals use templates
-+-
 Reporter:  jMyles   |Owner:  jMyles
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  contrib.auth, tests  | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by julien):

 This paradigm (overriding `TEMPLATE_DIRS` in `setUp()`) is a common way
 for *unit* tests to be self-contained and runnable in any environment.
 What's tricky here is that `auth` sends the `user_logged_in` signal but
 has no control over how that signal is used outside of the `auth` app
 during testing. The core issue is that there is no easy way of separating
 *unit* tests from *integration* tests in Django. Ideally when running
 tests from your project, you should only be interested in running
 integration tests and avoid running the various apps' unit tests -- So one
 approach is to simply exclude the `auth` tests from your project's test
 runner.

 Another approach would be to make the `auth`'s tests even more self-
 contained by initially backing up and deactivating the currently
 registered signal receivers, then registering its own temporary receiver
 for the pure purpose of unit testing, and finally restoring the backed up
 receivers. That way the `auth` tests wouldn't fail, but you probably would
 still have to write integration tests in your own project to verify that
 your custom signal receiver works as intended.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13875: cannot customize admin submit_row

2011-10-10 Thread Django

#13875: cannot customize admin submit_row
---+
 Reporter:  drul   |Owner:  dArignac
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  1.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+

Comment (by ramiro):

 In [16956]:
 {{{
 #!CommitTicketReference repository="" revision="16956"
 Fixed #9460 -- Added template blocks for submit buttons rows in admin app
 model add/change views.

 This allows for easier customization. Thanks kosmik for report and patch.

 Refs #13875.
 }}}

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #9460: Template blocks for submit buttons in admin's change view

2011-10-10 Thread Django

#9460: Template blocks for submit buttons in admin's change view
-+-
 Reporter:  kosmik   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  admin, submit,   | Triage Stage:  Accepted
  buttons, template  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by ramiro):

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


Comment:

 In [16956]:
 {{{
 #!CommitTicketReference repository="" revision="16956"
 Fixed #9460 -- Added template blocks for submit buttons rows in admin app
 model add/change views.

 This allows for easier customization. Thanks kosmik for report and patch.

 Refs #13875.
 }}}

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16956 - django/trunk/django/contrib/admin/templates/admin

2011-10-10 Thread noreply

Author: ramiro
Date: 2011-10-10 15:19:59 -0700 (Mon, 10 Oct 2011)
New Revision: 16956

Modified:
   django/trunk/django/contrib/admin/templates/admin/change_form.html
Log:
Fixed #9460 -- Added template blocks for submit buttons rows in admin app model 
add/change views.

This allows for easier customization. Thanks kosmik for report and patch.

Refs #13875.

Modified: django/trunk/django/contrib/admin/templates/admin/change_form.html
===
--- django/trunk/django/contrib/admin/templates/admin/change_form.html  
2011-10-10 17:32:33 UTC (rev 16955)
+++ django/trunk/django/contrib/admin/templates/admin/change_form.html  
2011-10-10 22:19:59 UTC (rev 16956)
@@ -40,7 +40,7 @@
 {% 
csrf_token %}{% block form_top %}{% endblock %}
 
 {% if is_popup %}{% endif %}
-{% if save_on_top %}{% submit_row %}{% endif %}
+{% if save_on_top %}{% block submit_buttons_top %}{% submit_row %}{% endblock 
%}{% endif %}
 {% if errors %}
 
 {% blocktrans count errors|length as counter %}Please correct the error 
below.{% plural %}Please correct the errors below.{% endblocktrans %}
@@ -64,7 +64,7 @@
 
 {% block after_related_objects %}{% endblock %}
 
-{% submit_row %}
+{% block submit_buttons_bottom %}{% submit_row %}{% endblock %}
 
 {% if adminform and add %}
document.getElementById("{{ 
adminform.first_field.id_for_label }}").focus();

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17032: Tests for contrib.auth fail if login signals use templates

2011-10-10 Thread Django

#17032: Tests for contrib.auth fail if login signals use templates
-+-
 Reporter:  jMyles   |Owner:  jMyles
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  contrib.auth, tests  | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by anonymous):

 I thought about providing a test, but I can't immediately think of a way
 to do it that is settings-independent.  Shall I 'fake it' by appending to
 settings.TEMPLATE_DIRS in the actual test?  I don't know of any other
 tests that employ this technique, so I'm not especially comfortable with
 it.  If you can point me to one that I can use as a reference for good
 practice, I'd be happy to.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17032: Tests for contrib.auth fail if login signals use templates

2011-10-10 Thread Django

#17032: Tests for contrib.auth fail if login signals use templates
-+-
 Reporter:  jMyles   |Owner:  jMyles
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  contrib.auth, tests  | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by julien):

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


Comment:

 This makes sense. Could you provide a test case reproducing this
 TemplateDoesNotExist exception? Thanks!

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15372: manage.py adds to sys.path and forcibly imports the parent dir of the settings module

2011-10-10 Thread Django

#15372: manage.py adds to sys.path and forcibly imports the parent dir of the
settings module
-+-
 Reporter:  Jorge Vargas |Owner:  russellm
     |   Status:  reopened
 Type:  Bug  |  Version:  SVN
Component:  Core (Other) |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by carljm):

 Much more detailed breakdown of the problem and proposed solution at
 http://groups.google.com/group/django-
 developers/browse_frm/thread/44b70a37ff73298b

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17032: Tests for contrib.auth fail if login signals use templates

2011-10-10 Thread Django

#17032: Tests for contrib.auth fail if login signals use templates
---+-
 Reporter:  jMyles |  Owner:  jMyles
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  1.3
 Severity:  Normal |   Keywords:  contrib.auth, tests
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+-
 The tests for contrib.auth override settings.TEMPLATE_DIRS in order to use
 the test templates, which are obviously required in order to have
 cognizable tests of the login system.

 However, if a project uses the user_logged_in signal to hook a function
 that uses django.template.loader.get_template(), the test will improperly
 raise TemplateDoesNotExist.

 Instead of ovverriding settings.TEMPLATE_DIRS, it makes more sense to
 simply create a new tuple, the first member of which is the location of
 the test templates.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15372: manage.py adds to sys.path and forcibly imports the parent dir of the settings module

2011-10-10 Thread Django

#15372: manage.py adds to sys.path and forcibly imports the parent dir of the
settings module
-+-
 Reporter:  Jorge Vargas |Owner:  russellm
     |   Status:  reopened
 Type:  Bug  |  Version:  SVN
Component:  Core (Other) |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by carljm):

 Added the patch as an attachment for those who prefer that; also created a
 pull request at https://github.com/django/django/pull/62, to allow for
 inline comments on the patch.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17031: Enable ModelForm to display as read-only

2011-10-10 Thread Django

#17031: Enable ModelForm to display as read-only
-+-
 Reporter:  ferdonline@… |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  read-only ModelForm  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Alex):

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


Comment:

 Marking as wontfix (I actually think it's a dupe as well).  Froms are for
 processing data, not rendering it.  #342 features further discussion on
 this issue.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12680: Floating submitbuttons

2011-10-10 Thread Django

#12680: Floating submitbuttons
-+-
 Reporter:  shoyer   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  submitbotton | Triage Stage:  Design
  design_ux  |  decision needed
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by anonymous):

 Replying to [comment:5 ramiro]:
 > Isn't this what
 
[https://docs.djangoproject.com/en/1.3/ref/contrib/admin/#django.contrib.admin.ModelAdmin.save_on_top
 ModelAdmin.save_on_top] is for?
 I would say {{{ ModelAdmin.save_on_top }}} solves the issue when the
 edit/change page fits in two screen of height. However, IMHO, it's quite
 common to have the edit/change pages spans over that when you have 2 or
 more inline formset for example.

 I think this ticket would be a good candidate for
 [https://groups.google.com/forum/#!forum/django-ux django-ux].

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12680: Floating submitbuttons

2011-10-10 Thread Django

#12680: Floating submitbuttons
-+-
 Reporter:  shoyer   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  submitbotton | Triage Stage:  Design
  design_ux  |  decision needed
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by ramiro):

 * needs_docs:  0 => 1
 * easy:   => 0


Comment:

 Isn't this what
 
[https://docs.djangoproject.com/en/1.3/ref/contrib/admin/#django.contrib.admin.ModelAdmin.save_on_top
 ModelAdmin.save_on_top] is for?

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17031: Enable ModelForm to display as read-only

2011-10-10 Thread Django

#17031: Enable ModelForm to display as read-only
--+-
 Reporter:  ferdonline@…  |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Forms |Version:  1.3
 Severity:  Normal|   Keywords:  read-only ModelForm
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 It seems there is not an easy way to define a ModelForm as having all its
 fields "read-only", so that the form can be used for only-displaying info,
 for instance to a non-authenticated user.
 I've seen several people looking for this feature with some nasty
 workarounds.

 A +/- clean hack is to define a function in the child class that goes
 iterates over the fields and defines the disabled attribute to the
 corresponding widget, like:

 {{{
 def set_readonly( self ):
 for field in self.fields:
 self.fields[field].required = False
 self.fields[field].widget.attrs['disabled'] = 'disabled'

 }}}

 is there a better way of doing this? If not, can you consider applying
 this solution to the main class (ModelForm)?

 Cheers!

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13106: Show confirmation page when deleting objects from an inline form

2011-10-10 Thread Django

#13106: Show confirmation page when deleting objects from an inline form
---+-
 Reporter:  bmjames|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.1
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+-
Changes (by ramiro):

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


Comment:

 I'm going to close this as a duplicate of #14411 that, although is newer,
 has sparked some discussion.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17025: sql/where.py WhereNode refactoring

2011-10-10 Thread Django

#17025: sql/where.py WhereNode refactoring
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:  orm cleanup  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 Suor: using cached attnames turned out to be a really good idea. Not only
 did id speed up large resultsets by a couple of percents (5% according to
 djangobench), but it is really good for qs.raw() when you don't have all
 the fields in the SQL, or when using qs.only() or qs.defer(). These are
 now a lot faster. See #17030 for details. I think that is the right place
 to discuss other ideas for model initialization speedup, too.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16307: Unable to expand (resolve) template variable attribute when the variable is a python class

2011-10-10 Thread Django

#16307: Unable to expand (resolve) template variable attribute when the 
variable is
a python class
-+
 Reporter:  sorin|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by rico):

 I think the best approach would be to not treat classes as callables.
 But I agree that this may lead to more problems than it fixes.

 I just don't agree that we shouldn't pass classes for templates, I think
 there are viable exceptions for this.

 For now I'm using a wrapper because I need to call a classmethod on the
 template:

 {{{
 class NonCallable(object):

 def __init__(self, wrapped):
 self._wrapped = wrapped

 def __getattr__(self, item):
 return getattr(self._wrapped, item)
 }}}

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17025: sql/where.py WhereNode refactoring

2011-10-10 Thread Django

#17025: sql/where.py WhereNode refactoring
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:  orm cleanup  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Mailing List SVR ):

 * cc: lists@… (added)


-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17029: django.dispatch.dispatcher.Signal should be pickleable

2011-10-10 Thread Django

#17029: django.dispatch.dispatcher.Signal should be pickleable
--+--
 Reporter:  d0ugal|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by gtaylor):

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


Comment:

 Very neat idea. We'd like this very much.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16307: Unable to expand (resolve) template variable attribute when the variable is a python class

2011-10-10 Thread Django

#16307: Unable to expand (resolve) template variable attribute when the 
variable is
a python class
-+
 Reporter:  sorin|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by lukeplant):

 I think catching `TypeError` would be a very bad idea. First, it only
 fixes one instance of the bigger problem, which has surfaced in other
 areas, namely that the template language calls classes instead of leaving
 them as they are. Catching the `TypeError` will only work for the case
 where the constructor takes required arguments. Just because you *can*
 call a class constructor with no arguments doesn't mean that that is what
 the template author intended. Second, catching `TypeError` could mask all
 kind of other errors in callables.

 I don't think there will be a nice solution to this. The best option would
 probably be to treat classes differently from other callables, and not
 call them. I suspect this could produce worse backwards incompatibilities,
 though.

 For the current problem, there is an easy work around: pass
 `MyReport.__dict__` instead of `MyReport`. Personally, I think the answer
 is "don't pass classes into templates, full stop". Classes are developer
 oriented objects, not meant as general datastructures suitable for use in
 templates.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16307: Unable to expand (resolve) template variable attribute when the variable is a python class

2011-10-10 Thread Django

#16307: Unable to expand (resolve) template variable attribute when the 
variable is
a python class
-+
 Reporter:  sorin|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by carljm):

 * status:  closed => reopened
 * version:  1.3 => SVN
 * resolution:  invalid =>
 * stage:  Unreviewed => Accepted


Comment:

 Re-opening based on rico's clarification.

 I'm not sure what the solution is, but I think this is a legitimate bug.
 Maybe a fallback to direct attribute access if calling a callable fails?
 That risks masking other deeper `TypeError` occurrences; I wish Python had
 a dedicated exception for wrong-arguments. The cure for this could be
 worse than the disease, which might mean it has be to wontfix - but I'll
 leave it open for now in case anyone has good ideas.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16307: Unable to expand (resolve) template variable attribute when the variable is a python class

2011-10-10 Thread Django

#16307: Unable to expand (resolve) template variable attribute when the 
variable is
a python class
-+--
 Reporter:  sorin|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.3
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by rico):

 I think this ticket was mistakenly closed.

 Sorin is trying to access the verbose_name of a '''app.reports.MyReport'''
 class, not the verbose_name of a model.

 When the template system tries to resolve a variable which is a class, it
 thinks the class is a callable and may fail to call (or instantiate) it
 due to missing arguments in the constructor.


 {{{
 class MyReport(object):
 verbose_name = "My Report"

 render_to_string('some/template.html', {'report_class': MyReport})
 }}}

 And the template:

 {{{
 Name: {{ report_class.verbose_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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16819: list_editable breaks multipage changelists

2011-10-10 Thread Django

#16819: list_editable breaks multipage changelists
-+
 Reporter:  anossov@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  admin list_editable  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by JannKleen):

 * cc: jann@… (added)


-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17029: django.dispatch.dispatcher.Signal should be pickleable

2011-10-10 Thread Django

#17029: django.dispatch.dispatcher.Signal should be pickleable
--+
 Reporter:  d0ugal|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Core (Other)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  1 |  UI/UX:  0
--+
 The Signal class contains an instance of threading.Lock which means it
 can't be pickled without providing pickle with some hints. It should be
 pickleable as it is passed in the kwargs to signal receivers, the use case
 that requires all arguments to be pickleable is best demonstrated as
 follows.

 This example uses a celery task as the receiver of a signal to in effect
 provide "async signals" which would allow for some nice patterns to be
 developed.

 {{{
 # In a models.py file in any project with celery already configured.
 from celery.task import task
 from django.db import models
 from django.db.models.signals import pre_delete, pre_save

 class MyModel(models.Model):
 pass

 @task(ignore_result=True)
 def async_post_save(sender, instance, **kwargs):
 # do something with the instance.
 pass

 post_save.connect(async_post_save.delay, sender=MyModel)
 }}}


 I've attached a patch for this which basically implements a very small
 monkey patch that I am currently using in a project.

 {{{
 from django.dispatch.dispatcher import Signal
 def reducer(self):
 return (Signal, (self.providing_args,))
 Signal.__reduce__ = reducer
 }}}


 As it happens, I quickly threw together a blog post about this trick:
 http://dougalmatthews.com/2011/10/10/making-django's-signals-asynchronous-
 with-celery/

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17028: diveintopython.org links now dead

2011-10-10 Thread Django

#17028: diveintopython.org links now dead
---+
 Reporter:  django@…   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * stage:  Unreviewed => 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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17028: diveintopython.org links now dead

2011-10-10 Thread Django

#17028: diveintopython.org links now dead
---+
 Reporter:  django@…   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The documentation links to diveintopython.org in five places, these are
 unfortunately now dead links :-(

  * `./intro/index.txt` line 34
  * `./ref/django-admin.txt` line 1171
  * `./ref/templates/builtins.txt` line 1920
  * `./topics/http/urls.txt` line 112
  * `./topics/settings.txt` line 42

 These should be removed or replaced with a mirror. Here are some random
 mirrors I found:
  * [http://www.faqs.org/docs/diveintopython/toc.html]
  *
 
[http://web.archive.org/web/20110716181728/http://www.diveintopython.org/toc/index.html]
  * [http://diveintopython.nfshost.com/]

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15624: aggregate produces incorrect sql statement

2011-10-10 Thread Django

#15624: aggregate produces incorrect sql statement
-+-
 Reporter:  zeroos <232002@…>|Owner:
 Type:  Bug  |  marekw2143
Component:  ORM aggregation  |   Status:  assigned
 Severity:  Normal   |  Version:  SVN
 Keywords:  aggregate sql|   Resolution:
  syntax error   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ramiro):

 * has_patch:  0 => 1
 * ui_ux:   => 0
 * needs_tests:  0 => 1
 * easy:   => 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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #7758: Can't override the form_url for change_view - like you can with add_view

2011-10-10 Thread Django

#7758: Can't override the form_url for change_view - like you can with add_view
-+-
 Reporter:  Rozza|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  newforms admin   | Triage Stage:  Accepted
  customization  |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by ramiro):

 * needs_docs:  0 => 1
 * needs_tests:  0 => 1
 * easy:  0 => 1


-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16954 - in django/trunk/docs: ref/contrib ref/contrib/admin ref/contrib/comments ref/models releases topics

2011-10-10 Thread noreply

Author: lukeplant
Date: 2011-10-10 08:32:01 -0700 (Mon, 10 Oct 2011)
New Revision: 16954

Modified:
   django/trunk/docs/ref/contrib/admin/index.txt
   django/trunk/docs/ref/contrib/comments/example.txt
   django/trunk/docs/ref/contrib/localflavor.txt
   django/trunk/docs/ref/models/querysets.txt
   django/trunk/docs/releases/1.0-alpha-1.txt
   django/trunk/docs/releases/1.0-alpha-2.txt
   django/trunk/docs/releases/1.0-beta-2.txt
   django/trunk/docs/releases/1.0-beta.txt
   django/trunk/docs/releases/1.0.txt
   django/trunk/docs/topics/auth.txt
   django/trunk/docs/topics/templates.txt
Log:
Fixed a bunch of ReST errors that resulted in interpretation as block quotations

Modified: django/trunk/docs/ref/contrib/admin/index.txt
===
--- django/trunk/docs/ref/contrib/admin/index.txt   2011-10-10 12:35:06 UTC 
(rev 16953)
+++ django/trunk/docs/ref/contrib/admin/index.txt   2011-10-10 15:32:01 UTC 
(rev 16954)
@@ -230,7 +230,7 @@
 
 This results in an admin page that looks like:
 
-.. image:: _images/flatfiles_admin.png
+.. image:: _images/flatfiles_admin.png
 
 If neither ``fieldsets`` nor :attr:`~ModelAdmin.fields` options are 
present,
 Django will default to displaying each field that isn't an ``AutoField`` 
and
@@ -577,7 +577,7 @@
 Set ``list_filter`` to activate filters in the right sidebar of the change
 list page of the admin, as illustrated in the following screenshot:
 
-.. image:: _images/users_changelist.png
+.. image:: _images/users_changelist.png
 
 ``list_filter`` should be a list of elements, where each element should be
 of one of the following types:

Modified: django/trunk/docs/ref/contrib/comments/example.txt
===
--- django/trunk/docs/ref/contrib/comments/example.txt  2011-10-10 12:35:06 UTC 
(rev 16953)
+++ django/trunk/docs/ref/contrib/comments/example.txt  2011-10-10 15:32:01 UTC 
(rev 16954)
@@ -40,7 +40,7 @@
 .. versionadded:: 1.2
 
 Next, we can use the :ttag:`render_comment_list` tag, to render all comments
-to the given instance (``entry``) by using the ``comments/list.html`` template.
+to the given instance (``entry``) by using the ``comments/list.html`` 
template::
 
{% render_comment_list for entry %}
 

Modified: django/trunk/docs/ref/contrib/localflavor.txt
===
--- django/trunk/docs/ref/contrib/localflavor.txt   2011-10-10 12:35:06 UTC 
(rev 16953)
+++ django/trunk/docs/ref/contrib/localflavor.txt   2011-10-10 15:32:01 UTC 
(rev 16954)
@@ -824,7 +824,7 @@
 
 .. class:: mx.forms.MXCURPField
 
-.. versionadded:: 1.4
+   .. versionadded:: 1.4
 
A field that validates a Mexican *Clave Única de Registro de Población*.
 

Modified: django/trunk/docs/ref/models/querysets.txt
===
--- django/trunk/docs/ref/models/querysets.txt  2011-10-10 12:35:06 UTC (rev 
16953)
+++ django/trunk/docs/ref/models/querysets.txt  2011-10-10 15:32:01 UTC (rev 
16954)
@@ -936,49 +936,49 @@
 
 * ``order_by``
 
-If you need to order the resulting queryset using some of the new
-fields or tables you have included via ``extra()`` use the ``order_by``
-parameter to ``extra()`` and pass in a sequence of strings. These
-strings should either be model fields (as in the normal
-:meth:`order_by()` method on querysets), of the form
-``table_name.column_name`` or an alias for a column that you specified
-in the ``select`` parameter to ``extra()``.
+  If you need to order the resulting queryset using some of the new
+  fields or tables you have included via ``extra()`` use the ``order_by``
+  parameter to ``extra()`` and pass in a sequence of strings. These
+  strings should either be model fields (as in the normal
+  :meth:`order_by()` method on querysets), of the form
+  ``table_name.column_name`` or an alias for a column that you specified
+  in the ``select`` parameter to ``extra()``.
 
-For example::
+  For example::
 
-q = Entry.objects.extra(select={'is_recent': "pub_date > 
'2006-01-01'"})
-q = q.extra(order_by = ['-is_recent'])
+  q = Entry.objects.extra(select={'is_recent': "pub_date > 
'2006-01-01'"})
+  q = q.extra(order_by = ['-is_recent'])
 
-This would sort all the items for which ``is_recent`` is true to the
-front of the result set (``True`` sorts before ``False`` in a
-descending ordering).
+  This would sort all the items for which ``is_recent`` is true to the
+  front of the result set (``True`` sorts before ``False`` in a
+  descending ordering).
 
-This shows, by the way, that you can make multiple calls to ``extra()``
-and it will behave as you expect (adding new constraints

Re: [Django] #8052: Password Change Forms overrides userlinks

2011-10-10 Thread Django

#8052: Password Change Forms overrides userlinks
---+
 Reporter:  mikeblake  |Owner:
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by ramiro):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => fixed
 * easy:   => 0


Comment:

 Fixed in r9079 and r12217. You can now provide your custom  templates for
 ''change password''-related views if you need this kind of customization.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17025: sql/where.py WhereNode refactoring

2011-10-10 Thread Django

#17025: sql/where.py WhereNode refactoring
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:  orm cleanup  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 About the errors when running the benchmark suite - turns out I was using
 a dirty version of the code. git checkout -- made the bechmark suite pass.
 Results are similar, if not better than above.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10523: Changing object with long repr causes error

2011-10-10 Thread Django

#10523: Changing object with long __repr__ causes error
---+-
 Reporter:  bromer |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.2-beta
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by ramiro):

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


Comment:

 I can run Julien's test case against PostgreSQL and MySQL without seeing
 the issue. Please provide a complete test case or field value example.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16679: Speed up signals by caching the reveicers per sender

2011-10-10 Thread Django

#16679: Speed up signals by caching the reveicers per sender
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by Suor):

 Here are another approach, without cache, store receivers by sender
 instead.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16371: model fieldname as css class in admin edit view

2011-10-10 Thread Django

#16371: model fieldname as css class in admin edit view
-+
 Reporter:  thomasbilk   |Owner:  silent1mezzo
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  css class admin  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+
Changes (by julien):

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


Comment:

 In [16953]:
 {{{
 #!CommitTicketReference repository="" revision="16953"
 Fixed #16371 -- Added a prefix "field-" to all CSS class names
 automatically generated from field names in admin forms to avoid conflicts
 with other common class names (e.g. "button"). This is backwards-
 incompatible for those who previously used plain field names as selector
 in custom style sheets or javascript transformations.
 }}}

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16953 - in django/trunk: django/contrib/admin/templates/admin/edit_inline django/contrib/admin/templates/admin/includes docs/releases tests/regressiontests/admin_views

2011-10-10 Thread noreply

Author: julien
Date: 2011-10-10 05:35:06 -0700 (Mon, 10 Oct 2011)
New Revision: 16953

Modified:
   django/trunk/django/contrib/admin/templates/admin/edit_inline/tabular.html
   django/trunk/django/contrib/admin/templates/admin/includes/fieldset.html
   django/trunk/docs/releases/1.4.txt
   django/trunk/tests/regressiontests/admin_views/tests.py
Log:
Fixed #16371 -- Added a prefix "field-" to all CSS class names automatically 
generated from field names in admin forms to avoid conflicts with other common 
class names (e.g. "button"). This is backwards-incompatible for those who 
previously used plain field names as selector in custom style sheets or 
javascript transformations.

Modified: 
django/trunk/django/contrib/admin/templates/admin/edit_inline/tabular.html
===
--- django/trunk/django/contrib/admin/templates/admin/edit_inline/tabular.html  
2011-10-10 00:23:47 UTC (rev 16952)
+++ django/trunk/django/contrib/admin/templates/admin/edit_inline/tabular.html  
2011-10-10 12:35:06 UTC (rev 16953)
@@ -44,7 +44,7 @@
 {% for fieldset in inline_admin_form %}
   {% for line in fieldset %}
 {% for field in line %}
-  
+  
   {% if field.is_readonly %}
   {{ field.contents }}
   {% else %}

Modified: 
django/trunk/django/contrib/admin/templates/admin/includes/fieldset.html
===
--- django/trunk/django/contrib/admin/templates/admin/includes/fieldset.html
2011-10-10 00:23:47 UTC (rev 16952)
+++ django/trunk/django/contrib/admin/templates/admin/includes/fieldset.html
2011-10-10 12:35:06 UTC (rev 16953)
@@ -4,7 +4,7 @@
 {{ fieldset.description|safe }}
 {% endif %}
 {% for line in fieldset %}
-
+
 {% if line.fields|length_is:'1' %}{{ line.errors }}{% endif %}
 {% for field in line %}
 

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2011-10-10 00:23:47 UTC (rev 16952)
+++ django/trunk/docs/releases/1.4.txt  2011-10-10 12:35:06 UTC (rev 16953)
@@ -431,6 +431,16 @@
 those icons to customize the admin then you will want to replace them with your
 own icons or retrieve them from a previous release.
 
+CSS class names in admin forms
+~~
+
+To avoid conflicts with other common CSS class names (e.g. "button"), a prefix
+"field-" has been added to all CSS class names automatically generated from the
+form field names in the main admin forms, stacked inline forms and tabular
+inline cells. You will need to take that prefix into account in your custom
+style sheets or javascript files if you previously used plain field names as
+selectors for custom styles or javascript transformations.
+
 Compatibility with old signed data
 ~~
 

Modified: django/trunk/tests/regressiontests/admin_views/tests.py
===
--- django/trunk/tests/regressiontests/admin_views/tests.py 2011-10-10 
00:23:47 UTC (rev 16952)
+++ django/trunk/tests/regressiontests/admin_views/tests.py 2011-10-10 
12:35:06 UTC (rev 16953)
@@ -2786,11 +2786,11 @@
 formats.localize(datetime.date.today() - 
datetime.timedelta(days=7))
 )
 
-self.assertContains(response, '')
-self.assertContains(response, '')
-self.assertContains(response, '')
-self.assertContains(response, '')
-self.assertContains(response, '')
+self.assertContains(response, '')
+self.assertContains(response, '')
+self.assertContains(response, '')
+self.assertContains(response, '')
+self.assertContains(response, '')
 self.assertContains(response, '', 3)
 self.assertContains(response, 'Some help text for the 
title (with unicode ŠĐĆŽćžšđ)')
 self.assertContains(response, 'Some help text for the 
content (with unicode ŠĐĆŽćžšđ)')
@@ -2983,6 +2983,33 @@
 self.assertEqual(response.status_code, 200)
 
 
+class CSSTest(TestCase):
+urls = "regressiontests.admin_views.urls"
+fixtures = ['admin-views-users.xml']
+
+def setUp(self):
+self.client.login(username='super', password='secret')
+
+def tearDown(self):
+self.client.logout()
+
+def test_css_classes(self):
+response = self.client.get('/test_admin/admin/admin_views/post/add/')
+
+# The main form
+self.assertContains(response, 'class="form-row field-title"')
+self.assertContains(response, 'class="form-row field-content"')
+

Re: [Django] #17025: sql/where.py WhereNode refactoring

2011-10-10 Thread Django

#17025: sql/where.py WhereNode refactoring
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:  orm cleanup  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Suor):

 Did you try
 {{{
 obj.__dict__.update(izip(attnames(cls), data))
 }}}
 It's the fastest way to fill model fields I found.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17025: sql/where.py WhereNode refactoring

2011-10-10 Thread Django

#17025: sql/where.py WhereNode refactoring
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:  orm cleanup  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 I tried that attnames approach. Unfortunately I didn't see any difference.
 When I tried with `__dict__`[attname] = val, I got around 20% speedup. I
 think it is the setattr calls that are the problem, and they can not be
 made faster easily. If I remove signals and manually do self.field1 =
 args[1], self.field2 = args[2] and so on, I will get the init down to 0.5
 seconds, or 50% faster for the 1000 objects from the DB test. Using raw
 SQL for the same query takes 0.2 seconds, so there is still some overhead,
 but not nearly as much.

 I would imagine 0.5 seconds speed would be possible for a C code /
 generated code `__init__`. Should be a fun little project to do that (of
 course as an external project).

 Re signal sending: #16679

 This is an interesting topic, but it is out of scope for this ticket.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17025: sql/where.py WhereNode refactoring

2011-10-10 Thread Django

#17025: sql/where.py WhereNode refactoring
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:  orm cleanup  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Suor):

 Under heavy load I get more model instances from cache than from db. So
 unpickling was a great issue for me.
 And I came up with https://gist.github.com/974735 to speed it up and same
 some space.

 Regarding `Model.__init__()` it looks like it should be optimized together
 with `QuertSet.iterator()`. Also, a common case when `len(args) ==
 len(self._meta.fields)` could be optimized by use of a precached list of
 field attnames instead of `fields_iter` (see gist above for `attnames()`
 function).

 The second optimization that comes to mind is optimizations of signals
 handling. Now system stores a list of handlers for each event and when a
 signal is sent it filters that list with `isinstance()` call to restrict
 sender. Storing handlers in a proper structure (a dict sender_class ->
 list of handlers looks nice) will make sending signals faster.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17025: sql/where.py WhereNode refactoring

2011-10-10 Thread Django

#17025: sql/where.py WhereNode refactoring
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:  orm cleanup  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 Yeah, true. I don't know anything about pickling / unpickling, but I have
 tried to make the model initialization faster. For example if you fetch
 1000 models from local SQLite DB, about 75% of the time is used in model
 `__init__`. As far as I can see, the `__init__` is as fast as possible
 without going to code generation or C coding, and without breaking
 backwards compatibility.

 I actually think I will make an external CFastModel one day. It implements
 a custom `__init__` method but is otherwise just like normal Model. I
 haven't got a clue how hard that is to do, because I haven't done any
 Python extensions in C. And that is the reason why I am going to try to do
 it :)

 I will try to test this ticket's patch with models containing more fields.
 I suspect the more fields, the lesser the effect of this patch. It would
 also be interesting to test select_related calls, queries with joins and
 so on. For those interested in this ticket, this is one way to help...

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17025: sql/where.py WhereNode refactoring

2011-10-10 Thread Django

#17025: sql/where.py WhereNode refactoring
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:  orm cleanup  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Suor):

 In my experience, 4 fields is uncommon for any models that actually store
 data, it's common for any categorizing or helper models.
 So testing with a model with 10+ fields would be more useful, it also
 affects model instance and pickling/unpickling construction time.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

44 matches

Mail list logo