Re: [Django] #9573: template filter length() should call .count() on querysets

[Django]

#9573: template filter length() should call .count() on querysets
---+
  Reporter:  wam   | Owner:  nobody
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by miracle2k):

  * status:  closed => reopened
  * resolution:  wontfix =>
  * version:  1.0 => 1.1
  * component:  Template system => Database layer (models, ORM)

Comment:

 I just stumbled across this; For some reason I always assumed that {{
 queryset|length }} would do a count() when possible.

 Couldn't this be handled inside the ORM? I.e. __len__ doing a count()
 query for as of yet unexecuted querysets, and continuing to fetch the
 remainder of the result if the queryset was already touched?

 Clearly there is the downside of running an extra query in cases where the
 result is pulled later on anyway, but it may be worth the compromise.

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

[Django] #12216: typo in flatpages docs

[Django]

#12216: typo in flatpages docs
---+
 Reporter:  carljm |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 There's a "not" in the flatpages docs where it doesn't belong:

 {{{
 Also make sure you’ve correctly set SITE_ID to the ID of the site the
 settings file represents.
 This will usually be 1 (i.e. SITE_ID = 1, but if you’re not using the
 sites framework to manage multiple sites, it could be the ID of a
 different site.
 }}}

 It's if you _are_ using the sites framework to manage multiple sites that
 it could be the ID of a different site.

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

Re: [Django] #12215: ModelChoiceIterator doesn't define __len__

[Django]

#12215: ModelChoiceIterator doesn't define __len__
-+--
  Reporter:  Alex| Owner:  nobody
Status:  new | Milestone:  1.2   
 Component:  Forms   |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

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

[Django] #12215: ModelChoiceIterator doesn't define __len__

[Django]

#12215: ModelChoiceIterator doesn't define __len__
---+
 Reporter:  Alex   |   Owner:  nobody
   Status:  new|   Milestone:  1.2   
Component:  Forms  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 This means one can't necessarily call len(field.choices) if
 hasattr(field.choices), which would be nice.

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

Re: [Django] #12214: never_cache decorator breaks HttpResponse with iterator content

[Django]

#12214: never_cache decorator breaks HttpResponse with iterator content
---+
  Reporter:  bendavis78| Owner:  nobody
Status:  new   | Milestone:
 Component:  Cache system  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by bendavis78):

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

Comment:

 One possibility is to just use a universally unique id for streamed
 content, since we can't ever predict the unique nature of streamed
 content.

 {{{
 #!python
 import uuid
 response['ETag'] = '"%s"' % uuid.uuid4().get_hex()
 }}}

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

[Django] #12214: never_cache decorator breaks HttpResponse with iterator content

[Django]

#12214: never_cache decorator breaks HttpResponse with iterator content
--+-
 Reporter:  bendavis78|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Cache system  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 This generally isn't a problem, as normal views don't typically use
 never_cache.  However,  admin views use never_cache by default,  and if
 you're streaming content from the result of an admin action (for example,
 a very large csv file), you'll get an empty response.

 Code example:
 {{{
 #!python
 def export_assembly_list(self, request, batches):
 import csv
 from StringIO import StringIO

 #define output columns
 cols = get_csv_cols()

 stream = StringIO()
 writer = csv.writer(stream)
 def content():
 writer.writerow([k for k,v in cols])
 yield stream.getvalue()
 stream.truncate(0)

 for batch in batches:
 for invitation in batch.invitations.values(*[v for k,v in
 cols]):
 writer.writerow([invitation[v] for k,v in cols])
 yield stream.getvalue()
 stream.truncate(0)

 return

 response = HttpResponse(content(), mimetype='text/csv')
 response['Content-Disposition'] = 'attachment;
 filename=batch_assembly_list.csv'
 return response

 }}}

 What happens is this:  never_cache() calls
 django.utils.cache.add_never_cache_headers(), which calls
 patch_response_headers().  This function adds the ETag header to the
 response,  and to get the ETag, it does this:
 {{{
 #!python
 if not response.has_header('ETag'):
 response['ETag'] = '"%s"' %
 md5_constructor(response.content).hexdigest()
 }}}
 response.content, in turn,  does {{{"".join(self._container)}}},  which
 causes the iterator to "complete".  The problem with this is that the next
 time the iterator is called, the cursor is already at the end of the
 iterator, thus the empty response.

 The workaround is easy but not at all obvious: just define the Etag on
 your response.

 The overall fix should be just as easy: In the patch_response_headers()
 function, just detect if the response content is an iterator, and if so
 use a different method for generating the ETag.  Although, I have no idea
 what that should be.

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

[Changeset] r11739 - in django/trunk/django/contrib/gis: gdal gdal/tests tests/data/test_vrt

[noreply]

Author: jbronn
Date: 2009-11-14 17:25:44 -0600 (Sat, 14 Nov 2009)
New Revision: 11739

Modified:
   django/trunk/django/contrib/gis/gdal/geometries.py
   django/trunk/django/contrib/gis/gdal/geomtype.py
   django/trunk/django/contrib/gis/gdal/tests/test_ds.py
   django/trunk/django/contrib/gis/gdal/tests/test_geom.py
   django/trunk/django/contrib/gis/tests/data/test_vrt/test_vrt.vrt
Log:
`OGRGeomType` now recognizes 2.5D types, and removes need for unnecessary 
workaround in `Layer.geom_type`; corrected geometry type in test VRT file.  
Refs #11433.


Modified: django/trunk/django/contrib/gis/gdal/geometries.py
===
--- django/trunk/django/contrib/gis/gdal/geometries.py  2009-11-14 19:13:33 UTC 
(rev 11738)
+++ django/trunk/django/contrib/gis/gdal/geometries.py  2009-11-14 23:25:44 UTC 
(rev 11739)
@@ -214,13 +214,7 @@
 @property
 def geom_type(self):
 "Returns the Type for this Geometry."
-try:
-return OGRGeomType(capi.get_geom_type(self.ptr))
-except OGRException:
-# VRT datasources return an invalid geometry type
-# number, but a valid name -- we'll try that instead.
-# See: http://trac.osgeo.org/gdal/ticket/2491
-return OGRGeomType(capi.get_geom_name(self.ptr))
+return OGRGeomType(capi.get_geom_type(self.ptr))
 
 @property
 def geom_name(self):
@@ -684,4 +678,11 @@
6 : MultiPolygon,
7 : GeometryCollection,
101: LinearRing,
+   1 + OGRGeomType.wkb25bit : Point,
+   2 + OGRGeomType.wkb25bit : LineString,
+   3 + OGRGeomType.wkb25bit : Polygon,
+   4 + OGRGeomType.wkb25bit : MultiPoint,
+   5 + OGRGeomType.wkb25bit : MultiLineString,
+   6 + OGRGeomType.wkb25bit : MultiPolygon,
+   7 + OGRGeomType.wkb25bit : GeometryCollection,
}

Modified: django/trunk/django/contrib/gis/gdal/geomtype.py
===
--- django/trunk/django/contrib/gis/gdal/geomtype.py2009-11-14 19:13:33 UTC 
(rev 11738)
+++ django/trunk/django/contrib/gis/gdal/geomtype.py2009-11-14 23:25:44 UTC 
(rev 11739)
@@ -4,6 +4,8 @@
 class OGRGeomType(object):
 "Encapulates OGR Geometry Types."
 
+wkb25bit = -2147483648
+
 # Dictionary of acceptable OGRwkbGeometryType s and their string names.
 _types = {0 : 'Unknown',
   1 : 'Point',
@@ -15,6 +17,13 @@
   7 : 'GeometryCollection',
   100 : 'None',
   101 : 'LinearRing',
+  1 + wkb25bit: 'Point25D',
+  2 + wkb25bit: 'LineString25D',
+  3 + wkb25bit: 'Polygon25D',
+  4 + wkb25bit: 'MultiPoint25D',
+  5 + wkb25bit : 'MultiLineString25D',
+  6 + wkb25bit : 'MultiPolygon25D',
+  7 + wkb25bit : 'GeometryCollection25D',
   }
 # Reverse type dictionary, keyed by lower-case of the name.
 _str_types = dict([(v.lower(), k) for k, v in _types.items()])
@@ -68,7 +77,7 @@
 @property
 def django(self):
 "Returns the Django GeometryField for this OGR Type."
-s = self.name
+s = self.name.replace('25D', '')
 if s in ('LinearRing', 'None'):
 return None
 elif s == 'Unknown':

Modified: django/trunk/django/contrib/gis/gdal/tests/test_ds.py
===
--- django/trunk/django/contrib/gis/gdal/tests/test_ds.py   2009-11-14 
19:13:33 UTC (rev 11738)
+++ django/trunk/django/contrib/gis/gdal/tests/test_ds.py   2009-11-14 
23:25:44 UTC (rev 11739)
@@ -23,7 +23,7 @@
   
srs_wkt='GEOGCS["GCS_WGS_1984",DATUM["WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]',
   field_values={'dbl' : [float(i) for i in range(1, 6)], 'int' 
: range(1, 6), 'str' : [str(i) for i in range(1, 6)]},
   fids=range(5)),
-   TestDS('test_vrt', ext='vrt', nfeat=3, nfld=3, geom='POINT', 
gtype=1, driver='VRT',
+   TestDS('test_vrt', ext='vrt', nfeat=3, nfld=3, geom='POINT', 
gtype='Point25D', driver='VRT',
   fields={'POINT_X' : OFTString, 'POINT_Y' : OFTString, 'NUM' 
: OFTString}, # VRT uses CSV, which all types are OFTString.
   extent=(1.0, 2.0, 100.0, 523.5), # Min/Max from CSV
   field_values={'POINT_X' : ['1.0', '5.0', '100.0'], 'POINT_Y' 
: ['2.0', '23.0', '523.5'], 'NUM' : ['5', '17', '23']},

Modified: django/trunk/django/contrib/gis/gdal/tests/test_geom.py
===
--- django/trunk/django/contrib/gis/gdal/tests/test_geom.py 2009-11-14 
19:13:33 UTC (rev 11738)
+++ django/trunk/django/contrib/gis/gdal/tests/test_geom.py 2009-11-14 
23:25:44 

[Changeset] r11738 - in django/trunk/docs: . releases

[noreply]

Author: lukeplant
Date: 2009-11-14 13:13:33 -0600 (Sat, 14 Nov 2009)
New Revision: 11738

Added:
   django/trunk/docs/releases/1.2.txt
Removed:
   django/trunk/docs/releases/1.2-alpha.txt
Modified:
   django/trunk/docs/index.txt
   django/trunk/docs/releases/1.1.txt
   django/trunk/docs/releases/index.txt
Log:
Fixed #12198 - CSRF changes not clearly noted in docs.

The docs no longer unhelpfully point to BackwardsIncompatibleChanges,
and instead a section has been added to help those upgrading and
those following trunk.  Tentative 1.2 release notes added.



Modified: django/trunk/docs/index.txt
===
--- django/trunk/docs/index.txt 2009-11-13 12:35:05 UTC (rev 11737)
+++ django/trunk/docs/index.txt 2009-11-14 19:13:33 UTC (rev 11738)
@@ -201,7 +201,5 @@
 
 * **Django over time:**
   :ref:`API stability ` |
-  :ref:`Archive of release notes ` | 
`Backwards-incompatible changes`_ |
+  :ref:`Release notes ` |
   :ref:`Deprecation Timeline `
-
-.. _Backwards-incompatible changes: 
http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges

Modified: django/trunk/docs/releases/1.1.txt
===
--- django/trunk/docs/releases/1.1.txt  2009-11-13 12:35:05 UTC (rev 11737)
+++ django/trunk/docs/releases/1.1.txt  2009-11-14 19:13:33 UTC (rev 11738)
@@ -14,9 +14,11 @@
 
 .. _new features: `What's new in Django 1.1`_
 
-Backwards-incompatible changes
-==
+.. _backwards-incompatible-changes-1.1:
 
+Backwards-incompatible changes in 1.1
+=
+
 Django has a policy of :ref:`API stability `. This means
 that, in general, code you develop against Django 1.0 should continue to work
 against 1.1 unchanged. However, we do sometimes make backwards-incompatible
@@ -150,6 +152,8 @@
 backwards-incompatible if you were using the ``redirect_to`` view with a
 format-string key called 'permanent', which is highly unlikely.
 
+.. _deprecated-features-1.1:
+
 Features deprecated in 1.1
 ==
 

Deleted: django/trunk/docs/releases/1.2-alpha.txt
===
--- django/trunk/docs/releases/1.2-alpha.txt2009-11-13 12:35:05 UTC (rev 
11737)
+++ django/trunk/docs/releases/1.2-alpha.txt2009-11-14 19:13:33 UTC (rev 
11738)
@@ -1,52 +0,0 @@
-
-Backwards-incompatible changes
-==
-
-CSRF Protection

-
-There have been large changes to the way that CSRF protection works, detailed 
in
-:ref:`the CSRF documentaton `.  The following are the major
-changes that developers must be aware of:
-
- * ``CsrfResponseMiddleware`` and ``CsrfMiddleware`` have been deprecated, and
-   will be removed completely in Django 1.4, in favour of a template tag that
-   should be inserted into forms.
-
- * All contrib apps use a ``csrf_protect`` decorator to protect the view.  This
-   requires the use of the csrf_token template tag in the template, so if you
-   have used custom templates for contrib views, you MUST READ THE UPGRADE
-   INSTRUCTIONS to fix those templates.
-
- * ``CsrfViewMiddleware`` is included in :setting:`MIDDLEWARE_CLASSES` by
-   default. This turns on CSRF protection by default, so that views that accept
-   POST requests need to be written to work with the middleware.  Instructions
-   on how to do this are found in the CSRF docs.
-
- * All of the CSRF has moved from contrib to core (with backwards compatible
-   imports in the old locations, which are deprecated).
-
-LazyObject
---
-
-``LazyObject`` is an undocumented utility class used for lazily wrapping other
-objects of unknown type.  In Django 1.1 and earlier, it handled introspection 
in
-a non-standard way, depending on wrapped objects implementing a public method
-``get_all_members()``. Since this could easily lead to name clashes, it has 
been
-changed to use the standard method, involving ``__members__`` and 
``__dir__()``.
-If you used ``LazyObject`` in your own code, and implemented the
-``get_all_members()`` method for wrapped objects, you need to make the 
following
-changes:
-
- * If your class does not have special requirements for introspection (i.e. you
-   have not implemented ``__getattr__()`` or other methods that allow for
-   attributes not discoverable by normal mechanisms), you can simply remove the
-   ``get_all_members()`` method.  The default implementation on ``LazyObject``
-   will do the right thing.
-
- * If you have more complex requirements for introspection, first rename the
-   ``get_all_members()`` method to ``__dir__()``.  This is the standard method,
-   from Python 2.6 onwards, for supporting introspection.  If you are require
-   support for Python < 2.6, add the following code to the class::
-
-   __members__ = property(lambda self: self.__dir__())

Copied: django/trunk/docs/releases/1.2.txt (from rev 11709, 

Re: [Django] #12213: Initial data and addition queryset_filter for formset from inlineformset_factory

[Django]

#12213: Initial data and addition queryset_filter for formset from
inlineformset_factory
+---
  Reporter:  ramusus| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  1 
Needs_better_patch:  0  |  
+---
Changes (by ramusus):

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

Re: [Django] #12202: Hardcoded subject in the reset password mail

[Django]

#12202: Hardcoded subject in the reset password mail
-+--
  Reporter:  anonymous   | Owner:  agabel 
Status:  assigned| Milestone:  1.2
 Component:  Authentication  |   Version:  1.1
Resolution:  |  Keywords:  reset password mail
 Stage:  Accepted| Has_patch:  0  
Needs_docs:  1   |   Needs_tests:  1  
Needs_better_patch:  0   |  
-+--
Changes (by agabel):

  * component:  django.contrib.admin => Authentication

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

[Django] #12213: Initial data and addition queryset_filter for formset from inlineformset_factory

[Django]

#12213: Initial data and addition queryset_filter for formset from
inlineformset_factory
---+
 Reporter:  ramusus|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 To the continue of the discussion here: http://groups.google.ru/group
 /django-developers/browse_thread/thread/73af9e58bd7626a8/e307d4865759a26e

 I also need the ability to define initial data for formset from
 inlineformset_factory. It's very strange to limit this by the framework
 for inlineformset_factory, but not limit for modelformset_factory.

 Queryset parameter created automatically inside inlineformset_factory, but
 I can imagine situation, when it's necessary to generate form and formset
 with not all linked objects. For example If I need to see formset with
 instances, filtered by special condition, based on fields. For this
 purpose I added queryset_filter parameter, that passed as a kwargs
 argument into queryset.filter(**queryset_filter).

 Formsets is a great mechanism, that simplify many routine operations with
 linked objects. I think it's better to have ability tune this mecanism in
 detail.

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

Re: [Django] #12202: Hardcoded subject in the reset password mail

[Django]

#12202: Hardcoded subject in the reset password mail
---+
  Reporter:  anonymous | Owner:  agabel 
Status:  assigned  | Milestone:  1.2
 Component:  django.contrib.admin  |   Version:  1.1
Resolution:|  Keywords:  reset password mail
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  1 |   Needs_tests:  1  
Needs_better_patch:  0 |  
---+
Changes (by agabel):

  * status:  new => assigned
  * component:  Authentication => django.contrib.admin
  * needs_tests:  0 => 1
  * milestone:  => 1.2
  * owner:  nobody => agabel
  * needs_docs:  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-upda...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #7048: Support clearing FileFields with ModelForms

[Django]

#7048: Support clearing FileFields with ModelForms
---+
  Reporter:  jarrow| Owner:  brosner
Status:  assigned  | Milestone:  1.2
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  1  
Needs_better_patch:  0 |  
---+
Changes (by kahless):

 * cc: herbert.p...@gmail.com (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-upda...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=.

Re: [Django] #11362: CSRF middleware XHTML conformance

[Django]

#11362: CSRF middleware XHTML conformance
---+
  Reporter:  loren | Owner:  nobody
Status:  closed| Milestone:  1.2   
 Component:  Contrib apps  |   Version:  SVN   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by andriijas):

 * cc: andr...@klydd.se (removed)

Comment:

 > The policy in Django is that you don't re-open a bug that is closed by a
 core committer without discussion on django-devs.  Please do not re-open.

 Didnt know about that (the ticket didnt say it was closed by a "core
 comitter". Sorry.

 And about the rest... I don't have the energy to argue about it. Though
 it's a shame there's no "html guidlines" or something to maintain
 consistency.

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

Re: [Django] #11362: CSRF middleware XHTML conformance

[Django]

#11362: CSRF middleware XHTML conformance
---+
  Reporter:  loren | Owner:  nobody
Status:  closed| Milestone:  1.2   
 Component:  Contrib apps  |   Version:  SVN   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by lukeplant):

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

Comment:

 Replying to [comment:2 andriijas]:

 > Lame excuse for closing. Double quoting should be used since
 >
 > 1) Consistency, Its used everywhere else in django

 This is not true.

 > 2) Single quoted html comes from the world of php idiocy ( print ""; )

 HTML did not inherit its use of single quotes from PHP practices.
 Equivalent things are done in the Django code base i.e. single quotes used
 to avoid problems with nesting quotations. See
 
http://code.djangoproject.com/browser/django/tags/releases/1.1/django/views/debug.py#L489
 for example.

 > 3) Why on earth wrap a display none div around an input hidden field? If
 you are afraid of margins and paddings added by user style sheet, just put
 display none on the input.

 Without the div, you have invalid HTML.  The div has "display:none" to
 defensively protect against older browsers and their rendering quirks.
 (I'm not sure if there is a specific bug with any, but I'm not going to
 fire up a Windows VM and try X versions of Internet Explorer just to
 check, and it can't harm, and I've run across related bugs in the past).

 > 4) Anyone closing this issue again without the patch being apply
 obviously don't care about consistency and clean markup, which does matter
 to some people. So lets not make something big of this. It's a quick job
 to review and apply the patch, though I understand it will take some
 minutes of someones precious spare time.

 If I changed the quoting style, I'd could well have another bug filed from
 someone else who was relying on the previous style for some reason (e.g.
 if they had a regression test that checked the exact output of a page),
 and they would actually have a better case — why did I change something
 that wasn't broken?  What am I going to put in the commit message -
 "Changed some valid HTML to some other valid HTML because andriijas told
 me so"?

 And if I applied your patch as is, I'd have HTML errors immediately.
 Perhaps you haven't thought this through as well as you thought?

 Yes, reviewing this patch did waste some minutes of my precious spare
 time.  I don't begrudge them, but I do object to the attitude that says
 that you have a right to them, or the idea that if the review does not
 turn out how you want then obviously I have no valid reasons for doing
 turning you down.

 > It's all about the semantics.

 The semantics are not affected, I have no idea what you mean here.

 The policy in Django is that you don't re-open a bug that is closed by a
 core committer without discussion on django-devs.  Please do not re-open.

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

Re: [Django] #11362: CSRF middleware XHTML conformance

[Django]

#11362: CSRF middleware XHTML conformance
---+
  Reporter:  loren | Owner:  nobody
Status:  reopened  | Milestone:  1.2   
 Component:  Contrib apps  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by andriijas):

 * cc: andr...@klydd.se (added)
  * milestone:  => 1.2

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

Re: [Django] #11362: CSRF middleware XHTML conformance

[Django]

#11362: CSRF middleware XHTML conformance
---+
  Reporter:  loren | Owner:  nobody
Status:  reopened  | Milestone:
 Component:  Contrib apps  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by andriijas):

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

Comment:

 Replying to [comment:1 lukeplant]:
 > Single quotes for attributes are valid XHTML.

 Lame excuse for closing. Double quoting should be used since
 1) Consistency, Its used everywhere else in django
 2) Single quoted html comes from the world of php idiocy ( print ""; )
 3) Why on earth wrap a display none div around an input hidden field? If
 you are afraid of margins and paddings added by user style sheet, just put
 display none on the input.
 4) Anyone closing this issue again without the patch being apply obviously
 don't care about consistency and clean markup, which does matter to some
 people. So lets not make something big of this. It's a quick job to review
 and apply the patch, though I understand it will take some minutes of
 someones precious spare time.

 It's all about the semantics.

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