[Changeset] r11599 - django/trunk/docs/topics

[noreply]

Author: ubernostrum
Date: 2009-09-30 01:40:34 -0500 (Wed, 30 Sep 2009)
New Revision: 11599

Modified:
   django/trunk/docs/topics/testing.txt
Log:
Fixed #11961: Corrected a few typos in docs/testing.txt. Thanks to timo for the 
patch.

Modified: django/trunk/docs/topics/testing.txt
===
--- django/trunk/docs/topics/testing.txt2009-09-30 06:35:31 UTC (rev 
11598)
+++ django/trunk/docs/topics/testing.txt2009-09-30 06:40:34 UTC (rev 
11599)
@@ -515,7 +515,7 @@
 >>> c = Client()
 >>> c.get('/customers/details/?name=fred&age=7')
 
-If you provide URL both an encoded GET data and a data argument,
+If you provide a URL with both an encoded GET data and a data argument,
 the data argument will take precedence.
 
 If you set ``follow`` to ``True`` the client will follow any redirects
@@ -627,7 +627,7 @@
 
 .. versionadded:: 1.1
 
-Makes an PUT request on the provided ``path`` and returns a
+Makes a PUT request on the provided ``path`` and returns a
 ``Response`` object. Useful for testing RESTful interfaces. Acts just
 like :meth:`Client.post` except with the PUT request method.
 
@@ -1127,11 +1127,11 @@
 
 During test running, each outgoing e-mail is saved in
 ``django.core.mail.outbox``. This is a simple list of all
-:class:`<~django.core.mail.EmailMessage>` instances that have been sent.
+:class:`~django.core.mail.EmailMessage` instances that have been sent.
 It does not exist under normal execution conditions, i.e., when you're not
 running unit tests. The outbox is created during test setup, along with the
-dummy :class:`<~django.core.mail.SMTPConnection>`. When the test framework is
-torn down, the standard :class:`<~django.core.mail.SMTPConnection>` class is
+dummy :class:`~django.core.mail.SMTPConnection`. When the test framework is
+torn down, the standard :class:`~django.core.mail.SMTPConnection` class is
 restored, and the test outbox is destroyed.
 
 The ``outbox`` attribute is a special attribute that is created *only* when


--~--~-~--~~~---~--~~
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] r11598 - djangoproject.com/djangodocs/templates/docs

[noreply]

Author: ubernostrum
Date: 2009-09-30 01:35:31 -0500 (Wed, 30 Sep 2009)
New Revision: 11598

Modified:
   djangoproject.com/djangodocs/templates/docs/doc.html
Log:
Fixed #8885 and its many duplicates (hopefully) by stripping HTML (which 
implies mark_safe) to titles of documentation pages.

Modified: djangoproject.com/djangodocs/templates/docs/doc.html
===
--- djangoproject.com/djangodocs/templates/docs/doc.html2009-09-28 
22:04:20 UTC (rev 11597)
+++ djangoproject.com/djangodocs/templates/docs/doc.html2009-09-30 
06:35:31 UTC (rev 11598)
@@ -1,6 +1,6 @@
 {% extends "base_docs.html" %}
 
-{% block title %}{{ doc.title }} | Django Documentation{% endblock %}
+{% block title %}{{ doc.title|striptags }} | Django Documentation{% endblock %}
 
 {% block extrahead %}
   {{ block.super }}


--~--~-~--~~~---~--~~
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] #9519: QuerySet.delete() should operate with respect to previous query operations

[Django]

#9519: QuerySet.delete() should operate with respect to previous query 
operations
---+
  Reporter:  Tarken| Owner:  nobody 
   
Status:  new   | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  1.0
   
Resolution:|  Keywords:  database, 
queryset, delete
 Stage:  Design decision needed| Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by tobias):

 * cc: tobias (added)

Comment:

 This is an issue for me as well.  Imagine the cycle:

 1) SELECT 100 of the objects you want to delete (this can take awhile
 depending on the WHERE clause)

 2) DELETE those objects by ID

 Now imagine it repeated 1 times.  I'm trying to delete millions of
 rows from a table, so the current way .delete() works is completely
 unusable.

 IMHO .delete should just use the FROM table, JOINs (if any), and WHERE
 clause from the queryset itself.

-- 
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] #11739: ContentFile() does not support unicode data

[Django]

#11739: ContentFile() does not support unicode data
---+
  Reporter:  adamnelson| Owner:  nobody
Status:  new   | Milestone:
 Component:  File uploads/storage  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by adamnelson):

 It's an issue for me still, on Leopard.  Can nobody else reproduce?

-- 
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] #5786: Relax character restrictions on auth usernames

[Django]

#5786: Relax character restrictions on auth usernames
-+--
  Reporter:  Armin Ronacher  | Owner:  nobody   
   
Status:  new | Milestone:   
   
 Component:  Authentication  |   Version:  1.1  
   
Resolution:  |  Keywords:  username, 
character, restriction
 Stage:  Design decision needed  | Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Changes (by alextreme):

 * cc: alex-dja...@aperte.nl (added)
  * has_patch:  0 => 1
  * version:  => 1.1
  * stage:  Unreviewed => Design decision needed

Comment:

 I've included a very simple patch (django-auth-username-characters.patch,
 6 lines in 1 file) against Django 1.1 that eases the username
 restrictions. It allows the following characters (next to alphanumerics):
 @.+-_

 The auth system actually works perfectly fine with these characters, it's
 only the admin forms that restrict input. This probably was different in
 the past.

 I'm not sure if there was a rationale on restricting usernames (perhaps
 their use in URLs?) but this patch only allows a few more characters,
 those that probably cause the most annoyances.

 No major changes, no extra settings and good enough until #3011 sees some
 progress. Tests and a review are welcome however.

-- 
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] #11965: A ModelAdmin method returning bool is not formatted with an image

[Django]

#11965: A ModelAdmin method returning bool is not formatted with an image
---+
  Reporter:  romkyns   | Owner:  nobody  
Status:  closed| Milestone:  
 Component:  django.contrib.admin  |   Version:  SVN 
Resolution:  wontfix   |  Keywords:  list_display
 Stage:  Unreviewed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by lukeplant):

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

Comment:

 Given we already have one way of controlling whether this behaviour
 occurs, I think it's inappropriate to automatically do it as well.  The
 analogy to a boolean model field fails because you **have** specified very
 explicitly that the field is boolean by using !BooleanField (or
 something), which is not the same as a method that happens to return a
 boolean value, but it could be anything.

 Secondly, the autodetection fails if you have a method that happens to use
 0 for False and 1 for True, which some (old-ish) Python libraries still
 do, and it also fails if you want 'None' to return the 'unknown' graphic
 (as it does for null boolean model fields).

 These things considered, it's better to just keep a single, explicit
 method that always works.

-- 
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] #11965: A ModelAdmin method returning bool is not formatted with an image

[Django]

#11965: A ModelAdmin method returning bool is not formatted with an image
---+
  Reporter:  romkyns   | Owner:  nobody  
Status:  new   | Milestone:  
 Component:  django.contrib.admin  |   Version:  SVN 
Resolution:|  Keywords:  list_display
 Stage:  Unreviewed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by romkyns):

 You're right, I haven't seen it.

 Still, it seems natural that if a boolean model field gets this styling
 automatically (i.e. without me specifying any extra properties anywhere)
 then so should a modeladmin method returning bool. Do you think such
 behaviour would be inappropriate?

-- 
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] #11965: A ModelAdmin method returning bool is not formatted with an image

[Django]

#11965: A ModelAdmin method returning bool is not formatted with an image
---+
  Reporter:  romkyns   | Owner:  nobody  
Status:  new   | Milestone:  
 Component:  django.contrib.admin  |   Version:  SVN 
Resolution:|  Keywords:  list_display
 Stage:  Unreviewed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

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

Comment:

 Just in case you haven't seen it, the currently way to not only achieve
 but also control this is documented (fifth item in the second bullted
 list):

 
http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display

 (namely, specifying a `True` value for the `.boolean` attribute for the
 boolean-returning method.)

 Is there a reason you are proposing to expose second, more limited way to
 do to 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 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10130: Support setting deletion

[Django]

#10130: Support setting deletion
+---
  Reporter:  jcassee| Owner:  jcassee 
Status:  new| Milestone:  1.2 
 Component:  Core framework |   Version:  SVN 
Resolution: |  Keywords:  settings
 Stage:  Ready for checkin  | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by SmileyChris):

  * stage:  Accepted => Ready for checkin

-- 
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] #11965: A ModelAdmin method returning bool is not formatted with an image

[Django]

#11965: A ModelAdmin method returning bool is not formatted with an image
--+-
 Reporter:  romkyns   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  SVN   
 Keywords:  list_display  |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Consider the following model admin:

 {{{
 class AppleAdmin(admin.ModelAdmin):
 list_display = ('has_something',)

 def has_something(self, apple):
 return apple.something != None
 }}}

 The "has_something" method returns a bool. When viewing this model through
 the list of "apples" in the admin, the "has_something" column will
 currently simply say "True/False", whereas a boolean that's actually part
 of the "apple" model will be formatted with a special graphic.

 Trivial 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] #9002: Easy way to create mock Request objects for testing views

[Django]

#9002: Easy way to create mock Request objects for testing views
+---
  Reporter:  simon  | Owner:  kkubasik
Status:  new| Milestone:  
 Component:  Testing framework  |   Version:  1.0 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by peterbe):

 Replying to [comment:7 kkubasik]:
 > I have added support in django.test.mocks based on the snippet. Still
 needs docs and tests.
 Where? In a branch? I can't find anything in the trunk.

-- 
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] #10130: Support setting deletion

[Django]

#10130: Support setting deletion
-+--
  Reporter:  jcassee | Owner:  jcassee 
Status:  new | Milestone:  1.2 
 Component:  Core framework  |   Version:  SVN 
Resolution:  |  Keywords:  settings
 Stage:  Accepted| Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by jcassee):

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

Re: [Django] #10706: Incorrect error from manage.py sql when app fails to load

[Django]

#10706: Incorrect error from manage.py sql when app fails to load
--+-
  Reporter:  Glenn| Owner:  nobody
Status:  new  | Milestone:
 Component:  django-admin.py  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Comment (by cwb):

 This is easy to bump into and very puzzling (though with the beneficial
 side-effect that I properly dug into sys.path, relative imports and the
 like). For me the fix (to loading.py) didn't work with admindocs enabled
 (not just the tests) because that doesn't have a models module. Still
 helpful though -- got me out of my pickle.

-- 
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] #11877: Document that request.get_host() fails when behind multiple reverse proxies

[Django]

#11877: Document that request.get_host() fails when behind multiple reverse 
proxies
+---
  Reporter:  tomevans222| Owner:  nobody  
Status:  new| Milestone:  
 Component:  Documentation  |   Version:  1.0 
Resolution: |  Keywords:  proxy forwarded get_host
 Stage:  Accepted   | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by tomevans222):

 That sounds perfectly reasonable Jacob. I'll try to get a doc patch up as
 soon as $JOB allows :)

-- 
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] #11863: Add a method to the orm to create Model instances from raw sql queries

[Django]

#11863: Add a method to the orm to create Model instances from raw sql queries
---+
  Reporter:  seanoc| Owner:  seanoc
Status:  assigned  | Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  1 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by alexkoshelev):

 * cc: alexkoshelev (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
-~--~~~~--~~--~--~---