Re: [Django] #10559: Documentation fix in comments customization page

[Django]

#10559: Documentation fix in comments customization page
--+-
  Reporter:  thejaswi_puthraya| Owner:  nobody  
  
Status:  new  | Milestone:  1.1 
  
 Component:  django.contrib.comments  |   Version:  SVN 
  
Resolution:   |  Keywords:  comments, 
customization, documentation
 Stage:  Unreviewed   | Has_patch:  1   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Comment (by thejaswi_puthraya):

 Replying to [comment:2 mtredinnick]:
 > Documentation fixes aren't feature additions. Slow down a bit with
 moving things to 1.1 beta. This is a normal bug that will be fixed in the
 normal flow of things.

 Sorry about mis-labeling and thanks for pointing out the difference
 between the 1.1 and 1.1beta tag.

-- 
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] #8928: Make a WSGI compatibility layer for Django middleware

[Django]

#8928: Make a WSGI compatibility layer for Django middleware
+---
  Reporter:  simon  | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

 * cc: dane.springme...@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-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] r10105 - django/trunk/django/db/backends/sqlite3

[noreply]

Author: jbronn
Date: 2009-03-19 22:57:21 -0500 (Thu, 19 Mar 2009)
New Revision: 10105

Modified:
   django/trunk/django/db/backends/sqlite3/base.py
Log:
Fixed #9628 -- Use `pysqlite2` for database backend, if installed.


Modified: django/trunk/django/db/backends/sqlite3/base.py
===
--- django/trunk/django/db/backends/sqlite3/base.py 2009-03-20 03:57:12 UTC 
(rev 10104)
+++ django/trunk/django/db/backends/sqlite3/base.py 2009-03-20 03:57:21 UTC 
(rev 10105)
@@ -3,7 +3,8 @@
 
 Python 2.3 and 2.4 require pysqlite2 (http://pysqlite.org/).
 
-Python 2.5 and later use the sqlite3 module in the standard library.
+Python 2.5 and later can use a pysqlite2 module or the sqlite3 module in the
+standard library.
 """
 
 from django.db.backends import *
@@ -14,18 +15,18 @@
 
 try:
 try:
+from pysqlite2 import dbapi2 as Database
+except ImportError, e1:
 from sqlite3 import dbapi2 as Database
-except ImportError, e1:
-from pysqlite2 import dbapi2 as Database
 except ImportError, exc:
 import sys
 from django.core.exceptions import ImproperlyConfigured
 if sys.version_info < (2, 5, 0):
-module = 'pysqlite2'
+module = 'pysqlite2 module'
+exc = e1
 else:
-module = 'sqlite3'
-exc = e1
-raise ImproperlyConfigured, "Error loading %s module: %s" % (module, exc)
+module = 'either pysqlite2 or sqlite3 modules (tried in that order)'
+raise ImproperlyConfigured, "Error loading %s: %s" % (module, exc)
 
 try:
 import decimal


--~--~-~--~~~---~--~~
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] r10104 - in django/trunk: django/db/models django/db/models/fields tests/regressiontests/custom_managers_regress

[noreply]

Author: mtredinnick
Date: 2009-03-19 22:57:12 -0500 (Thu, 19 Mar 2009)
New Revision: 10104

Modified:
   django/trunk/django/db/models/base.py
   django/trunk/django/db/models/fields/related.py
   django/trunk/tests/regressiontests/custom_managers_regress/models.py
Log:
Fixed #2698 -- Fixed deleting in the presence of custom managers.

A custom manager on a related object that filtered away objects would prevent
those objects being deleted via the relation. This is now fixed.

Modified: django/trunk/django/db/models/base.py
===
--- django/trunk/django/db/models/base.py   2009-03-20 02:50:48 UTC (rev 
10103)
+++ django/trunk/django/db/models/base.py   2009-03-20 03:57:12 UTC (rev 
10104)
@@ -519,7 +519,17 @@
 else:
 sub_obj._collect_sub_objects(seen_objs, self.__class__, 
related.field.null)
 else:
-for sub_obj in getattr(self, rel_opts_name).all():
+# To make sure we can access all elements, we can't use the
+# normal manager on the related object. So we work directly
+# with the descriptor object.
+for cls in self.__class__.mro():
+if rel_opts_name in cls.__dict__:
+rel_descriptor = cls.__dict__[rel_opts_name]
+break
+else:
+raise AssertionError("Should never get here.")
+delete_qs = rel_descriptor.delete_manager(self).all()
+for sub_obj in delete_qs:
 sub_obj._collect_sub_objects(seen_objs, self.__class__, 
related.field.null)
 
 # Handle any ancestors (for the model-inheritance case). We do this by

Modified: django/trunk/django/db/models/fields/related.py
===
--- django/trunk/django/db/models/fields/related.py 2009-03-20 02:50:48 UTC 
(rev 10103)
+++ django/trunk/django/db/models/fields/related.py 2009-03-20 03:57:12 UTC 
(rev 10104)
@@ -188,7 +188,7 @@
 return getattr(instance, self.cache_name)
 except AttributeError:
 params = {'%s__pk' % self.related.field.name: 
instance._get_pk_val()}
-rel_obj = self.related.model._default_manager.get(**params)
+rel_obj = self.related.model._base_manager.get(**params)
 setattr(instance, self.cache_name, rel_obj)
 return rel_obj
 
@@ -296,13 +296,36 @@
 if instance is None:
 return self
 
+return self.create_manager(instance,
+self.related.model._default_manager.__class__)
+
+def __set__(self, instance, value):
+if instance is None:
+raise AttributeError, "Manager must be accessed via instance"
+
+manager = self.__get__(instance)
+# If the foreign key can support nulls, then completely clear the 
related set.
+# Otherwise, just move the named objects into the set.
+if self.related.field.null:
+manager.clear()
+manager.add(*value)
+
+def delete_manager(self, instance):
+"""
+Returns a queryset based on the related model's base manager (rather
+than the default manager, as returned by __get__). Used by
+Model.delete().
+"""
+return self.create_manager(instance,
+self.related.model._base_manager.__class__)
+
+def create_manager(self, instance, superclass):
+"""
+Creates the managers used by other methods (__get__() and delete()).
+"""
 rel_field = self.related.field
 rel_model = self.related.model
 
-# Dynamically create a class that subclasses the related
-# model's default manager.
-superclass = self.related.model._default_manager.__class__
-
 class RelatedManager(superclass):
 def get_query_set(self):
 return 
superclass.get_query_set(self).filter(**(self.core_filters))
@@ -352,17 +375,6 @@
 
 return manager
 
-def __set__(self, instance, value):
-if instance is None:
-raise AttributeError, "Manager must be accessed via instance"
-
-manager = self.__get__(instance)
-# If the foreign key can support nulls, then completely clear the 
related set.
-# Otherwise, just move the named objects into the set.
-if self.related.field.null:
-manager.clear()
-manager.add(*value)
-
 def create_many_related_manager(superclass, through=False):
 """Creates a manager that subclasses 'superclass' (which is a Manager)
 and adds behavior for many-to-many related objects."""

Modified: django/trunk/tests/regressiontests/custom_managers_regress/models.py
===
--- django/trunk/tests/regressiontests/custom_managers_regress/models.py
2009

Re: [Django] #9628: Using pysqlite2 instead of sqlite3 when needed

[Django]

#9628: Using pysqlite2 instead of sqlite3 when needed
---+
  Reporter:  mdh   | Owner:  jbronn
Status:  assigned  | Milestone:  1.1   
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  1 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jbronn):

  * owner:  nobody => jbronn
  * status:  new => assigned
  * stage:  Design decision needed => Accepted
  * milestone:  => 1.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
-~--~~~~--~~--~--~---

Re: [Django] #10559: Documentation fix in comments customization page

[Django]

#10559: Documentation fix in comments customization page
--+-
  Reporter:  thejaswi_puthraya| Owner:  nobody  
  
Status:  new  | Milestone:  1.1 
  
 Component:  django.contrib.comments  |   Version:  SVN 
  
Resolution:   |  Keywords:  comments, 
customization, documentation
 Stage:  Unreviewed   | Has_patch:  1   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Changes (by mtredinnick):

  * milestone:  1.1 beta => 1.1

Comment:

 Documentation fixes aren't feature additions. Slow down a bit with moving
 things to 1.1 beta. This is a normal bug that will be fixed in the normal
 flow of things.

-- 
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] #10559: Documentation fix in comments customization page

[Django]

#10559: Documentation fix in comments customization page
--+-
  Reporter:  thejaswi_puthraya| Owner:  nobody  
  
Status:  new  | Milestone:  1.1 beta
  
 Component:  django.contrib.comments  |   Version:  SVN 
  
Resolution:   |  Keywords:  comments, 
customization, documentation
 Stage:  Unreviewed   | Has_patch:  1   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Changes (by thejaswi_puthraya):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * needs_tests:  => 0
  * milestone:  1.1 => 1.1 beta

-- 
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] #9958: Split contrib.comments CommentForm class to allow easier customization

[Django]

#9958: Split contrib.comments CommentForm class to allow easier customization
--+-
  Reporter:  arne | Owner:  nobody  
   
Status:  new  | Milestone:  1.1 beta
   
 Component:  django.contrib.comments  |   Version:  SVN 
   
Resolution:   |  Keywords:  comments, 
customization
 Stage:  Design decision needed   | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Changes (by thejaswi_puthraya):

  * has_patch:  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
-~--~~~~--~~--~--~---

Re: [Django] #9958: Split contrib.comments CommentForm class to allow easier customization

[Django]

#9958: Split contrib.comments CommentForm class to allow easier customization
--+-
  Reporter:  arne | Owner:  nobody  
   
Status:  new  | Milestone:  1.1 beta
   
 Component:  django.contrib.comments  |   Version:  SVN 
   
Resolution:   |  Keywords:  comments, 
customization
 Stage:  Design decision needed   | Has_patch:  0   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Changes (by thejaswi_puthraya):

  * milestone:  => 1.1 beta

Comment:

 Is a fairly simple and backwards-compatible fix that could make into
 1.1beta

-- 
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] #10559: Documentation fix in comments customization page

[Django]

#10559: Documentation fix in comments customization page
+---
 Reporter:  thejaswi_puthraya   |   Owner:  nobody
   Status:  new |   Milestone:  1.1   
Component:  django.contrib.comments | Version:  SVN   
 Keywords:  comments, customization, documentation  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 The current documentation mentions that all the custom comment models must
 subclass from the `BaseCommentAbstractModel` which is not totally right.
 In the example in the documentation, it adds a `title` field to the model
 after subclassing from `BaseCommentAbstractModel` but the `form`
 subclassed from `CommentForm` displays the Name, Email, URL etc. So these
 extra form fields like Name, Email etc are not saved into the db and is an
 easy way of confusing people.

 Ideally, most cases would require to just subclass from the `Comment`
 model. Only in special cases, there will be a requirement to subclass from
 the `BaseCommentAbstractModel`.

 So I have added a patch to clarify in the documentation.

-- 
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] #9284: BaseModelFormSet and BaseInlineFormSet should call ModelForm.save() when saving objects

[Django]

#9284: BaseModelFormSet and BaseInlineFormSet should call ModelForm.save() when
saving objects
-+--
  Reporter:  dro...@gmail.com| Owner:  nobody
Status:  reopened| Milestone:
 Component:  Forms   |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jkocherhans):

  * status:  closed => reopened
  * summary:  Formsets don't call form's save => BaseModelFormSet and
  BaseInlineFormSet should call ModelForm.save()
  when saving objects
  * has_patch:  0 => 1
  * resolution:  invalid =>
  * stage:  Unreviewed => Design decision needed

Old description:

> Would it not be better to have the formset call each form's save method
> explicitly when the formset's save is called?
> It seems it would make some logic more centralized.

New description:

 The most current code is at http://github.com/jkocherhans/django/tree
 /formset-updates

 This introduces some backwards incompatibilities for people who overrode
 either type of formset's {{{__init__}}} method, but this is how I would
 have written the model formset code if we'd actually had modelforms first.
 This doesn't really solve any specific problems that I know of.

-- 
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] #9303: comment templatetags should be independent of Comment model

[Django]

#9303: comment templatetags should be independent of Comment model
--+-
  Reporter:  thejaswi_puthraya| Owner:  nobody  
  
Status:  reopened | Milestone:  1.1 beta
  
 Component:  django.contrib.comments  |   Version:  SVN 
  
Resolution:   |  Keywords:  comments, 
templatetags, independent, customize
 Stage:  Accepted | Has_patch:  1   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Changes (by thejaswi_puthraya):

  * has_patch:  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
-~--~~~~--~~--~--~---

Re: [Django] #9303: comment templatetags should be independent of Comment model

[Django]

#9303: comment templatetags should be independent of Comment model
--+-
  Reporter:  thejaswi_puthraya| Owner:  nobody  
  
Status:  reopened | Milestone:  1.1 beta
  
 Component:  django.contrib.comments  |   Version:  SVN 
  
Resolution:   |  Keywords:  comments, 
templatetags, independent, customize
 Stage:  Accepted | Has_patch:  0   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Changes (by thejaswi_puthraya):

  * status:  closed => reopened
  * resolution:  fixed =>
  * milestone:  => 1.1 beta

Comment:

 This bug still exists because the filter on `is_public` is being tried
 even before the fieldnames are checked. Looks like this line was
 overlooked while being checked in...

 This bug was identified in
 http://code.djangoproject.com/ticket/8630#comment:23.

-- 
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] #10548: BaseCommentAbstractModel does not include is_public field needed for template tags

[Django]

#10548: BaseCommentAbstractModel does not include is_public field needed for
template tags
--+-
  Reporter:  carljm   | Owner:  nobody
Status:  closed   | Milestone:
 Component:  django.contrib.comments  |   Version:  SVN   
Resolution:  invalid  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by thejaswi_puthraya):

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

Comment:

 Thanks for opening this ticket but this issue was almost addressed and
 requires some work on the documentation side.
 Please check http://code.djangoproject.com/ticket/8630#comment:25 for more
 details.

-- 
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] #8630: Improve the comments framework customizability

[Django]

#8630: Improve the comments framework customizability
--+-
  Reporter:  thejaswi_puthraya| Owner:  carljm  
   
Status:  closed   | Milestone:  
   
 Component:  django.contrib.comments  |   Version:  SVN 
   
Resolution:  fixed|  Keywords:  comments, 
customization
 Stage:  Accepted | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by thejaswi_puthraya):

 Hi Josh,

 Thanks for your comments. They have been invaluable and they have helped
 us locate a bug elsewhere.

 Replying to [comment:23 joshvanwyck]:
 > Greetings,
 >
 > I'm trying to take advantage of the newest version of the django's
 customizable comments framework. I am  following all the documentation
 when I try and implement a simple comment system that has an additional
 field. I tried initially with a BooleanField, but have since resorted to
 trying to simply follow the example from the documentation provided.
 >
 > When I run it, I get the following error message:
 > Caught an exception while rendering: Cannot resolve keyword 'is_public'
 into field. Choices are: content_type, id, object_pk, site, title
 >
 > I suspect that this is a bug or either mistaken documentation, as I'm
 assuming if I follow the example online character for character it should
 work.
 >


 Ideally you should be subclassing from the Comment Model. But if your
 requirements are different, then BaseCommentAbstractModel should do. This
 problem was fixed in [9891] but there is a small typo in that.

 Will reopen that ticket and get it fixed. Also I will open a ticket for
 patching the documentation that makes it very clear.


 > A couple of things I've found by digging through the code. If we extend
 the BaseCommentAbstractModel, how can we receive the Comment model's
 fields? Why does line 84 of templatetags/comments.py contain is_public =
 true. This field will only exist if we have extended the Comment model but
 this isn't an option as we are supposed to extend the
 BaseCommentAbstractModel.
 >
 > Also the unit testing doesn't seem to test the rendering which is where
 the problems seem to be occurring.
 >
 > Maybe I'm completely off here, this is my first time posting any
 comments so if I have broken any posting rules please let me know.
 >
 > Thanks for your work on this portion.
 >
 > Josh

-- 
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] r10103 - django/trunk/django/contrib/gis/tests

[noreply]

Author: jbronn
Date: 2009-03-19 21:50:48 -0500 (Thu, 19 Mar 2009)
New Revision: 10103

Modified:
   django/trunk/django/contrib/gis/tests/__init__.py
Log:
GeoDjango test suite now takes advantage of `importlib` added in r10088.


Modified: django/trunk/django/contrib/gis/tests/__init__.py
===
--- django/trunk/django/contrib/gis/tests/__init__.py   2009-03-20 02:10:47 UTC 
(rev 10102)
+++ django/trunk/django/contrib/gis/tests/__init__.py   2009-03-20 02:50:48 UTC 
(rev 10103)
@@ -1,4 +1,5 @@
 import sys, unittest
+from django.utils.importlib import import_module
 
 def geo_suite():
 """
@@ -45,7 +46,7 @@
 test_suite_names.append('test_geoip')
 
 for suite_name in test_suite_names:
-tsuite = getattr(__import__('django.contrib.gis.tests', globals(), 
locals(), [suite_name]), suite_name)
+tsuite = import_module('django.contrib.gis.tests.' + suite_name)
 s.addTest(tsuite.suite())
 return s, test_apps
 
@@ -87,14 +88,13 @@
 for test_app in test_apps:
 module_name = 'django.contrib.gis.tests.%s' % test_app
 if mysql:
-test_module_name = 'tests_mysql'
+test_module = 'tests_mysql'
 else:
-test_module_name = 'tests'
+test_module = 'tests'
 new_installed.append(module_name)
 
 # Getting the model test suite
-tsuite = getattr(__import__('django.contrib.gis.tests.%s' % test_app, 
globals(), locals(), [test_module_name]),
- test_module_name)
+tsuite = import_module(module_name + '.' + test_module)
 gis_suite.addTest(tsuite.suite())
 
 # Resetting the loaded flag to take into account what we appended to


--~--~-~--~~~---~--~~
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] r10102 - django/trunk/django/contrib/gis/maps/google

[noreply]

Author: jbronn
Date: 2009-03-19 21:10:47 -0500 (Thu, 19 Mar 2009)
New Revision: 10102

Modified:
   django/trunk/django/contrib/gis/maps/google/gmap.py
Log:
Fixed #10480 -- made `icons` a property to add more flexibility.


Modified: django/trunk/django/contrib/gis/maps/google/gmap.py
===
--- django/trunk/django/contrib/gis/maps/google/gmap.py 2009-03-20 01:43:35 UTC 
(rev 10101)
+++ django/trunk/django/contrib/gis/maps/google/gmap.py 2009-03-20 02:10:47 UTC 
(rev 10102)
@@ -71,9 +71,6 @@
 else:
 getattr(self, varname).append(overlay_class(overlay))
 
-# Pulling any icons from the markers.
-self.icons = [marker.icon for marker in self.markers if marker.icon]
-
 # If GMarker, GPolygons, and/or GPolylines are used the zoom will be
 # automatically calculated via the Google Maps API.  If both a zoom
 # level and a center coordinate are provided with polygons/polylines,
@@ -143,6 +140,11 @@
 "Returns XHTML information needed for IE VML overlays."
 return mark_safe('http://www.w3.org/1999/xhtml"; %s>' % 
self.xmlns)
 
+@property
+def icons(self):
+"Returns a sequence of GIcon objects in this map."
+return [marker.icon for marker in self.markers if marker.icon]
+
 class GoogleMapSet(GoogleMap):
 
 def __init__(self, *args, **kwargs):
@@ -173,11 +175,6 @@
 else:
 self.maps = args
 
-# Creating the icons sequence from every map in this set.
-self.icons = []
-for map in self.maps:
-self.icons.extend(map.icons)
-
 # Generating DOM ids for each of the maps in the set.
 self.dom_ids = ['map%d' % i for i in xrange(len(self.maps))]
 
@@ -220,3 +217,10 @@
 # `google-multi.js`, which calls the load routines for
 # each one of the individual maps in the set.
 return mark_safe('onload="%s.load()"' % self.js_module)
+
+@property
+def icons(self):
+"Returns a sequence of all icons in each map of the set."
+icons = []
+for map in self.maps: icons.extend(map.icons)
+return icons


--~--~-~--~~~---~--~~
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] #10556: FastCGI import error after [10088]

[Django]

#10556: FastCGI import error after [10088]
+---
  Reporter:  Boo| Owner:  nobody  
Status:  closed | Milestone:  1.1 beta
 Component:  HTTP handling  |   Version:  SVN 
Resolution:  fixed  |  Keywords:  
 Stage:  Unreviewed | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

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

Comment:

 Fixed in r10101.

-- 
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] #9666: ssi tag don't works with context variables

[Django]

#9666: ssi tag don't works with context variables
--+-
  Reporter:  andrews  | Owner:  nobody
Status:  new  | Milestone:  1.1   
 Component:  Template system  |   Version:  SVN   
Resolution:   |  Keywords:  tag, ssi, template
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Comment (by UloPe):

 The above patch has a bug if  the ssi tag is used with a variable inside a
 loop.
 Since the variable is only "resolved" once subsequent .render() calls (to
 the same node) always return the result of the first invocation.

 I'll attach a fixed 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
-~--~~~~--~~--~--~---

[Changeset] r10101 - django/trunk/django/core/servers

[noreply]

Author: mtredinnick
Date: 2009-03-19 20:43:35 -0500 (Thu, 19 Mar 2009)
New Revision: 10101

Modified:
   django/trunk/django/core/servers/fastcgi.py
Log:
Fixed #10556 -- Fixed a problem in the fastcgi server after r10088.
Thanks, Boo.

Modified: django/trunk/django/core/servers/fastcgi.py
===
--- django/trunk/django/core/servers/fastcgi.py 2009-03-20 01:37:34 UTC (rev 
10100)
+++ django/trunk/django/core/servers/fastcgi.py 2009-03-20 01:43:35 UTC (rev 
10101)
@@ -129,7 +129,7 @@
 wsgi_opts['debug'] = False # Turn off flup tracebacks
 
 try:
-module = importlib_import_module('.%s' % flup_module, 'flup')
+module = importlib.import_module('.%s' % flup_module, 'flup')
 WSGIServer = module.WSGIServer
 except:
 print "Can't import flup." + flup_module


--~--~-~--~~~---~--~~
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] r10100 - django/trunk/django/test

[noreply]

Author: mtredinnick
Date: 2009-03-19 20:37:34 -0500 (Thu, 19 Mar 2009)
New Revision: 10100

Modified:
   django/trunk/django/test/testcases.py
Log:
Python 2.3 fix: assertTrue *still* doesn't exist in Python 2.3

The tests and testing framework should use failUnless() instead.

Modified: django/trunk/django/test/testcases.py
===
--- django/trunk/django/test/testcases.py   2009-03-20 01:37:11 UTC (rev 
10099)
+++ django/trunk/django/test/testcases.py   2009-03-20 01:37:34 UTC (rev 
10100)
@@ -278,7 +278,7 @@
 """
 if hasattr(response, 'redirect_chain'):
 # The request was a followed redirect
-self.assertTrue(len(response.redirect_chain) > 0,
+self.failUnless(len(response.redirect_chain) > 0,
 ("Response didn't redirect as expected: Response code was %d"
 " (expected %d)" % (response.status_code, status_code)))
 
@@ -453,4 +453,4 @@
 restore_transaction_methods()
 transaction.rollback()
 transaction.leave_transaction_management()
-connection.close()
\ No newline at end of file
+connection.close()


--~--~-~--~~~---~--~~
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] r10099 - in django/trunk: django/db/models tests/regressiontests/queries

[noreply]

Author: mtredinnick
Date: 2009-03-19 20:37:11 -0500 (Thu, 19 Mar 2009)
New Revision: 10099

Modified:
   django/trunk/django/db/models/base.py
   django/trunk/tests/regressiontests/queries/models.py
Log:
Fixed #10547 -- Worked around some odd behaviour in Python 2.3 and 2.4.

Calling the super() version of __reduce__ in Model.__reduce__ led to infinite
loops in Python prior to 2.5. We don't do that any longer.

Modified: django/trunk/django/db/models/base.py
===
--- django/trunk/django/db/models/base.py   2009-03-20 00:58:35 UTC (rev 
10098)
+++ django/trunk/django/db/models/base.py   2009-03-20 01:37:11 UTC (rev 
10099)
@@ -348,9 +348,9 @@
 need to do things manually, as they're dynamically created classes and
 only module-level classes can be pickled by the default path.
 """
+data = self.__dict__
 if not self._deferred:
-return super(Model, self).__reduce__()
-data = self.__dict__
+return (self.__class__, (), data)
 defers = []
 pk_val = None
 for field in self._meta.fields:

Modified: django/trunk/tests/regressiontests/queries/models.py
===
--- django/trunk/tests/regressiontests/queries/models.py2009-03-20 
00:58:35 UTC (rev 10098)
+++ django/trunk/tests/regressiontests/queries/models.py2009-03-20 
01:37:11 UTC (rev 10099)
@@ -895,6 +895,9 @@
 >>> q2 = pickle.loads(pickle.dumps(qs))
 >>> list(qs) == list(q2)
 True
+>>> q3 = pickle.loads(pickle.dumps(qs, pickle.HIGHEST_PROTOCOL))
+>>> list(qs) == list(q3)
+True
 
 Bug #7277
 >>> n1.annotation_set.filter(Q(tag=t5) | Q(tag__children=t5) | 
 >>> Q(tag__children__children=t5))


--~--~-~--~~~---~--~~
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] r10098 - django/trunk/django/utils

[noreply]

Author: mtredinnick
Date: 2009-03-19 19:58:35 -0500 (Thu, 19 Mar 2009)
New Revision: 10098

Modified:
   django/trunk/django/utils/_threading_local.py
Log:
More typo fixing. :-(

I'm crawling into my hole now.

Modified: django/trunk/django/utils/_threading_local.py
===
--- django/trunk/django/utils/_threading_local.py   2009-03-20 00:56:56 UTC 
(rev 10097)
+++ django/trunk/django/utils/_threading_local.py   2009-03-20 00:58:35 UTC 
(rev 10098)
@@ -146,7 +146,7 @@
 object.__setattr__(self, '_local__lock', RLock())
 
 if (args or kw) and (cls.__init__ is object.__init__):
-raise TypeError("Initialization arguments are not supported)
+raise TypeError("Initialization arguments are not supported")
 
 # We need to create the thread dict in anticipation of
 # __init__ being called, to make sure we don't call it


--~--~-~--~~~---~--~~
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] r10097 - django/trunk/django/utils

[noreply]

Author: mtredinnick
Date: 2009-03-19 19:56:56 -0500 (Thu, 19 Mar 2009)
New Revision: 10097

Modified:
   django/trunk/django/utils/_threading_local.py
Log:
Whoops. I left some debugging printing in r10096. Nothing to see here.

Modified: django/trunk/django/utils/_threading_local.py
===
--- django/trunk/django/utils/_threading_local.py   2009-03-20 00:51:54 UTC 
(rev 10096)
+++ django/trunk/django/utils/_threading_local.py   2009-03-20 00:56:56 UTC 
(rev 10097)
@@ -146,7 +146,7 @@
 object.__setattr__(self, '_local__lock', RLock())
 
 if (args or kw) and (cls.__init__ is object.__init__):
-raise TypeError("Initialization arguments are not supported: %r, 
%r, %r" % (args, kw, cls.__init__ is object.__init__))
+raise TypeError("Initialization arguments are not supported)
 
 # We need to create the thread dict in anticipation of
 # __init__ being called, to make sure we don't call it


--~--~-~--~~~---~--~~
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] r10096 - django/trunk/django/utils

[noreply]

Author: mtredinnick
Date: 2009-03-19 19:51:54 -0500 (Thu, 19 Mar 2009)
New Revision: 10096

Modified:
   django/trunk/django/utils/_threading_local.py
Log:
Fixed database backend creation for Python 2.3.

Previously on "things we changed in the recent past" the database
connection setup was changed. People were happy. Except for those
running on Python 2.3.

We had completely broken Django on Python 2.3. Turns out, this is due to
a long-standing bug in the _threading_local module that interacts with
object creation in 2.3.

Interestingly, although the bug remains in Python 2.4 and 2.5, they
don't trip over it for reasons I don't entirely understand at the
moment.

Modified: django/trunk/django/utils/_threading_local.py
===
--- django/trunk/django/utils/_threading_local.py   2009-03-19 23:28:16 UTC 
(rev 10095)
+++ django/trunk/django/utils/_threading_local.py   2009-03-20 00:51:54 UTC 
(rev 10096)
@@ -145,8 +145,8 @@
 object.__setattr__(self, '_local__args', (args, kw))
 object.__setattr__(self, '_local__lock', RLock())
 
-if args or kw and (cls.__init__ is object.__init__):
-raise TypeError("Initialization arguments are not supported")
+if (args or kw) and (cls.__init__ is object.__init__):
+raise TypeError("Initialization arguments are not supported: %r, 
%r, %r" % (args, kw, cls.__init__ is object.__init__))
 
 # We need to create the thread dict in anticipation of
 # __init__ being called, to make sure we don't call it


--~--~-~--~~~---~--~~
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] #9101: Improved salt generation for django.contrib.auth

[Django]

#9101: Improved salt generation for django.contrib.auth
-+--
  Reporter:  toxik   | Owner:  nobody
Status:  new | Milestone:  1.1   
 Component:  Authentication  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 You can also add string.punctuation to the SALT_CHARS soup.

-- 
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] #10547: Delayed Loading Model Update Causes Recursive Errors

[Django]

#10547: Delayed Loading Model Update Causes Recursive Errors
---+
  Reporter:  megaman...@gmail.com  | Owner:  mtredinnick
Status:  assigned  | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  1.0
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * owner:  nobody => mtredinnick
  * status:  new => assigned

Comment:

 Ok, I've managed to replicate this now (the test suite does it, in fact)
 using Python 2.4.

-- 
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] #10558: 10470 and 10472 error. need to enter false in lieu of true.

[Django]

#10558: 10470 and 10472 error. need to enter false in lieu of true.
+---
  Reporter:  anonymous  | Owner:  nobody
Status:  closed | Milestone:
 Component:  django.contrib.databrowse  |   Version:  1.0   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

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

Comment:

 Closing as invalid in lieu of a reasonable description of a problem. Might
 be referring to #10470 and #10472, which are thread-safety bugs we
 recently fixed, but False and True don't appear in those patches.

-- 
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] #10558: 10470 and 10472 error. need to enter false in lieu of true.

[Django]

#10558: 10470 and 10472 error. need to enter false in lieu of true.
---+
 Reporter:  anonymous  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  django.contrib.databrowse  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  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] #10146: Support for contrib/markdown extension_configs in settings.py

[Django]

#10146: Support for contrib/markdown extension_configs in settings.py
---+
  Reporter:  bdejong   | Owner:  nobody 
 
Status:  new   | Milestone:  1.1
 
 Component:  Contrib apps  |   Version:  SVN
 
Resolution:|  Keywords:  markdown config extensions 
extension_configs
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by dc):

 Maybe MarkupField (#10317) will solve this in more generic and elegant
 way?

-- 
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] r10095 - in django/trunk/docs: ref topics/http

[noreply]

Author: lukeplant
Date: 2009-03-19 18:28:16 -0500 (Thu, 19 Mar 2009)
New Revision: 10095

Modified:
   django/trunk/docs/ref/settings.txt
   django/trunk/docs/topics/http/middleware.txt
Log:
Updated all refs to default middleware in docs.

(adding CSRF, removing XView which is no longer a default)



Modified: django/trunk/docs/ref/settings.txt
===
--- django/trunk/docs/ref/settings.txt  2009-03-19 23:14:20 UTC (rev 10094)
+++ django/trunk/docs/ref/settings.txt  2009-03-19 23:28:16 UTC (rev 10095)
@@ -760,10 +760,11 @@
 
 Default::
 
-("django.contrib.sessions.middleware.SessionMiddleware",
+("django.contrib.csrf.middleware.CsrfViewMiddleware",
+ "django.contrib.csrf.middleware.CsrfResponseMiddleware",
+ "django.contrib.sessions.middleware.SessionMiddleware",
  "django.contrib.auth.middleware.AuthenticationMiddleware",
- "django.middleware.common.CommonMiddleware",
- "django.middleware.doc.XViewMiddleware")
+ "django.middleware.common.CommonMiddleware")
 
 A tuple of middleware classes to use. See :ref:`topics-http-middleware`.
 

Modified: django/trunk/docs/topics/http/middleware.txt
===
--- django/trunk/docs/topics/http/middleware.txt2009-03-19 23:14:20 UTC 
(rev 10094)
+++ django/trunk/docs/topics/http/middleware.txt2009-03-19 23:28:16 UTC 
(rev 10095)
@@ -28,9 +28,10 @@
 
 MIDDLEWARE_CLASSES = (
 'django.middleware.common.CommonMiddleware',
+'django.contrib.csrf.middleware.CsrfViewMiddleware',
+'django.contrib.csrf.middleware.CsrfResponseMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
-'django.middleware.doc.XViewMiddleware',
 )
 
 During the request phases (:meth:`process_request` and :meth:`process_view`


--~--~-~--~~~---~--~~
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] #10557: FormWizard should not output raw HTML for previous_fields

[Django]

#10557: FormWizard should not output raw HTML for previous_fields
---+
 Reporter:  Matthew Flanagan   |   Owner:  nobody   
 
   Status:  new|   Milestone:   
 
Component:  django.contrib.formtools   | Version:  SVN  
 
 Keywords:  wizard |   Stage:  
Unreviewed
Has_patch:  1  |  
---+
 When using a {{{FormWizard}}} to generate forms it populates a context
 variable called {{{previous_fields}}} which contains raw HTML hidden
 fields for the previous step values and security hashes. This does not
 play well when you are trying to use the FormWizard in other types markup.

 My use case is that I'm using extjs for my application front-end and form
 presentation (though I could be using something else like XForms for
 example). I have a templatetag that spits out the appropriate extjs form
 widget when given a {{{bound field}}}. This fails for the {{{FormWizard}}}
 {{{previous_fields}}} because it is raw HTML.

 The patch attached turns {{{previous_fields}}} into a list of bound field
 objects that can be iterated over to output the same raw HTML as before or
 give you more control over the output.

-- 
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] r10094 - in django/trunk: django/conf django/conf/project_template docs/ref/contrib docs/releases

[noreply]

Author: lukeplant
Date: 2009-03-19 18:14:20 -0500 (Thu, 19 Mar 2009)
New Revision: 10094

Modified:
   django/trunk/django/conf/global_settings.py
   django/trunk/django/conf/project_template/settings.py
   django/trunk/docs/ref/contrib/csrf.txt
   django/trunk/docs/releases/1.1-alpha-1.txt
Log:
Added CSRF middleware to default settings and updated docs.

Updated docs to reflect the change, and the fact that using the
two separate middleware is preferred to using the combined one.



Modified: django/trunk/django/conf/global_settings.py
===
--- django/trunk/django/conf/global_settings.py 2009-03-19 22:46:49 UTC (rev 
10093)
+++ django/trunk/django/conf/global_settings.py 2009-03-19 23:14:20 UTC (rev 
10094)
@@ -301,10 +301,12 @@
 # this middleware classes will be applied in the order given, and in the
 # response phase the middleware will be applied in reverse order.
 MIDDLEWARE_CLASSES = (
+# 'django.middleware.gzip.GZipMiddleware',
+'django.contrib.csrf.middleware.CsrfViewMiddleware',
+'django.contrib.csrf.middleware.CsrfResponseMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 # 'django.middleware.http.ConditionalGetMiddleware',
-# 'django.middleware.gzip.GZipMiddleware',
 'django.middleware.common.CommonMiddleware',
 )
 

Modified: django/trunk/django/conf/project_template/settings.py
===
--- django/trunk/django/conf/project_template/settings.py   2009-03-19 
22:46:49 UTC (rev 10093)
+++ django/trunk/django/conf/project_template/settings.py   2009-03-19 
23:14:20 UTC (rev 10094)
@@ -59,6 +59,8 @@
 
 MIDDLEWARE_CLASSES = (
 'django.middleware.common.CommonMiddleware',
+'django.contrib.csrf.middleware.CsrfViewMiddleware',
+'django.contrib.csrf.middleware.CsrfResponseMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 )

Modified: django/trunk/docs/ref/contrib/csrf.txt
===
--- django/trunk/docs/ref/contrib/csrf.txt  2009-03-19 22:46:49 UTC (rev 
10093)
+++ django/trunk/docs/ref/contrib/csrf.txt  2009-03-19 23:14:20 UTC (rev 
10094)
@@ -7,46 +7,47 @@
 .. module:: django.contrib.csrf
:synopsis: Protects against Cross Site Request Forgeries
 
-The CsrfMiddleware class provides easy-to-use protection against
-`Cross Site Request Forgeries`_.  This type of attack occurs when a malicious
-Web site creates a link or form button that is intended to perform some action
-on your Web site, using the credentials of a logged-in user who is tricked
-into clicking on the link in their browser.
+The CsrfMiddleware classes provides easy-to-use protection against
+`Cross Site Request Forgeries`_.  This type of attack occurs when a
+malicious Web site creates a link or form button that is intended to
+perform some action on your Web site, using the credentials of a
+logged-in user who is tricked into clicking on the link in their
+browser.
 
 The first defense against CSRF attacks is to ensure that GET requests
-are side-effect free.  POST requests can then be protected by adding this
-middleware into your list of installed middleware.
+are side-effect free.  POST requests can then be protected by adding
+these middleware into your list of installed middleware.
 
 .. _Cross Site Request Forgeries: 
http://www.squarefree.com/securitytips/web-developers.html#CSRF
 
 How to use it
 =
 
-Add the middleware ``'django.contrib.csrf.middleware.CsrfMiddleware'`` to
-your list of middleware classes, :setting:`MIDDLEWARE_CLASSES`. It needs to 
process
-the response after the SessionMiddleware, so must come before it in the
-list. It also must process the response before things like compression
-happen to the response, so it must come after GZipMiddleware in the
-list.
+Add the middleware
+``'django.contrib.csrf.middleware.CsrfViewMiddleware'`` and
+``'django.contrib.csrf.middleware.CsrfResponseMiddleware'`` to your
+list of middleware classes,
+:setting:`MIDDLEWARE_CLASSES`. ``CsrfResponseMiddleware`` needs to
+process the response after the ``SessionMiddleware``, so must come
+before it in the list.  It also must process the response before
+things like compression happen to the response, so it must come after
+``GZipMiddleware`` in the list.
 
-The ``CsrfMiddleware`` class is actually composed of two middleware:
-``CsrfViewMiddleware`` which performs the checks on incoming requests,
-and ``CsrfResponseMiddleware`` which performs post-processing of the
-result.  This allows the individual components to be used and/or
-replaced instead of using ``CsrfMiddleware``.
+The ``CsrfMiddleware`` class, which combines the two classes, is also
+available, for backwards compatibility with Django 1.0.
 
 .. versioncha

Re: [Django] #5833: [newforms-admin] Custom FilterSpecs

[Django]

#5833: [newforms-admin] Custom FilterSpecs
---+
  Reporter:  Honza_Kral| Owner:  jkocherhans
 
Status:  assigned  | Milestone:  1.1 beta   
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  nfa-someday 
list_filter filterspec nfa-changelist ep2008
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  1  
 
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

 * cc: cian...@mbnet.fi (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] #4656: Allow In-depth serialization by specifying depth to follow relationship

[Django]

#4656: Allow In-depth serialization by specifying depth to follow relationship
-+--
  Reporter:  jay.m.mar...@gmail.com  | Owner:  nobody 
Status:  new | Milestone: 
 Component:  Serialization   |   Version:  SVN
Resolution:  |  Keywords:  feature
 Stage:  Accepted| Has_patch:  0  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Comment (by vitalyperessada):

 Another possible angle is to add QuerySet.deep_values() as per following
 posting. The code works on single object but it could be easily extended
 to work with iterator.
 http://groups.google.com/group/django-
 developers/browse_thread/thread/933cdb7b49880471

 I stumbled on this during json serialization attempt, but having something
 like deep_values() could have more future uses since it will allow
 converting django.models object tree into primitive nested data structure.

 If django gods agree :-) I could open a separate ticket and finalize code.

-- 
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] #10556: FastCGI import error after [10088]

[Django]

#10556: FastCGI import error after [10088]
---+
 Reporter:  Boo|   Owner:  nobody
   Status:  new|   Milestone:  1.1 beta  
Component:  HTTP handling  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 Typo fix in the patch below.

-- 
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] #3672: newforms: DateField doesn't handle date output formats

[Django]

#3672: newforms: DateField doesn't handle date output formats
+---
  Reporter:  ores...@gmail.com  | Owner:  ajs   
 
Status:  new| Milestone:
 
 Component:  Forms  |   Version:  SVN   
 
Resolution: |  Keywords:  DateField l10n 
localization format input output
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by taojonesin):

 * cc: tao_jone...@yahoo.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-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] r10093 - django/trunk/docs/ref/models

[noreply]

Author: mtredinnick
Date: 2009-03-19 17:46:49 -0500 (Thu, 19 Mar 2009)
New Revision: 10093

Modified:
   django/trunk/docs/ref/models/options.txt
Log:
Fixed #10546 -- Fixed a docs typo noticed by carljm.

Modified: django/trunk/docs/ref/models/options.txt
===
--- django/trunk/docs/ref/models/options.txt2009-03-19 22:46:28 UTC (rev 
10092)
+++ django/trunk/docs/ref/models/options.txt2009-03-19 22:46:49 UTC (rev 
10093)
@@ -100,7 +100,7 @@
 the correct tables are created as part of the test setup.
 
 If you're interested in changing the Python-level behaviour of a model class,
-you *could* use ``managed=True`` and create a copy of an existing model.
+you *could* use ``managed=False`` and create a copy of an existing model.
 However, there's a better approach for that situation: :ref:`proxy-models`.
 
 ``order_with_respect_to``


--~--~-~--~~~---~--~~
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] r10092 - django/trunk/tests/modeltests/defer

[noreply]

Author: mtredinnick
Date: 2009-03-19 17:46:28 -0500 (Thu, 19 Mar 2009)
New Revision: 10092

Modified:
   django/trunk/tests/modeltests/defer/models.py
Log:
Added a test for defer() / only() to make sure saving continues to work.

Modified: django/trunk/tests/modeltests/defer/models.py
===
--- django/trunk/tests/modeltests/defer/models.py   2009-03-19 09:43:45 UTC 
(rev 10091)
+++ django/trunk/tests/modeltests/defer/models.py   2009-03-19 22:46:28 UTC 
(rev 10092)
@@ -14,6 +14,9 @@
 value = models.CharField(max_length=50)
 related = models.ForeignKey(Secondary)
 
+def __unicode__(self):
+return self.name
+
 def count_delayed_fields(obj, debug=False):
 """
 Returns the number of delayed attributes on the given model instance.
@@ -86,4 +89,14 @@
 # KNOWN NOT TO WORK: >>> 
count_delayed_fields(qs.only('name').select_related('related')[0])
 # KNOWN NOT TO WORK >>> 
count_delayed_fields(qs.defer('related').select_related('related')[0])
 
+# Saving models with deferred fields is possible (but inefficient, since every
+# field has to be retrieved first).
+
+>>> obj = Primary.objects.defer("value").get(name="p1")
+>>> obj.name = "a new name"
+>>> obj.save()
+>>> Primary.objects.all()
+[]
+
+
 """}


--~--~-~--~~~---~--~~
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] #3011: Allow for extendable auth_user module

[Django]

#3011: Allow for extendable auth_user module
+---
  Reporter:  nowell strite  | Owner:  dan  
Status:  assigned   | Milestone:   
 Component:  Contrib apps   |   Version:   
Resolution: |  Keywords:  auth_user
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  1  |   Needs_tests:  1
Needs_better_patch:  1  |  
+---
Changes (by david):

 * cc: lar...@gmail.com (removed)
 * cc: david (added)

Comment:

 What about the new proxy Meta attribute? Did someone try to extends a User
 for real with it? http://docs.djangoproject.com/en/dev/topics/db/models
 /#proxy-models

-- 
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] #4604: session-based messages

[Django]

#4604: session-based messages
--+-
  Reporter:  Sean Patrick Hogan   | Owner:  
SmileyChris
Status:  new  | Milestone:  
1.2
 Component:  Contrib apps |   Version:  
SVN
Resolution:   |  Keywords:  
   
 Stage:  Accepted | Has_patch:  
1  
Needs_docs:  0|   Needs_tests:  
0  
Needs_better_patch:  1|  
--+-
Changes (by david):

 * cc: lar...@gmail.com (removed)

-- 
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] #6735: Class-based generic views

[Django]

#6735: Class-based generic views
+---
  Reporter:  jkocherhans| Owner:  telenieko
Status:  assigned   | Milestone:  1.1 beta 
 Component:  Generic views  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  1  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by david):

 * cc: lar...@gmail.com (removed)
 * cc: david (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] #17: Metasystem optimization: Share select_related in memory

[Django]

#17: Metasystem optimization: Share select_related in memory
---+
  Reporter:  adrian| Owner:  PhiR   

Status:  assigned  | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  feature 
caching
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  1 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Changes (by david):

 * cc: lar...@gmail.com (removed)
 * cc: david (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] #10508: Missing syntax highlighting in view code snippets in formset documentation

[Django]

#10508: Missing syntax highlighting in view code snippets in formset 
documentation
--+-
  Reporter:  Paul Menzel   | 
Owner:  nobody  
Status:  new  | 
Milestone:  1.1 
 Component:  Documentation|   
Version:  1.0 
Resolution:   |  
Keywords:  syntax error
 Stage:  Accepted | 
Has_patch:  0   
Needs_docs:  0|   
Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Comment (by timo):

 Does the patch actually highlight the code when you build it, mboersma?  I
 tried applying your patch and it doesn't highlight the text.  Like I said
 before, I think this issue has to do with the syntax highlighting parser
 failing due to what is technically invalid python (when a comment is used
 to describe what to do instead of writing python statements).

-- 
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] #10547: Delayed Loading Model Update Causes Recursive Errors

[Django]

#10547: Delayed Loading Model Update Causes Recursive Errors
---+
  Reporter:  megaman...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * stage:  Unreviewed => Accepted

Comment:

 Somebody's going to have to work out a slightly smaller example than "it
 happens somewhere in satchmo doing something unspecified". I can't see why
 recursive calls to `__reduce__()` should be happening, so I'm going to
 need a repeatable case to debug 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] #9977: CSRFMiddleware needs template tag

[Django]

#9977: CSRFMiddleware needs template tag
-+--
  Reporter:  bthomas | Owner:  nobody
Status:  new | Milestone:
 Component:  Uncategorized   |   Version:  1.0   
Resolution:  |  Keywords:  csrf  
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  0 
Needs_better_patch:  1   |  
-+--
Comment (by lukeplant):

 Replying to [comment:8 bthomas]:

 > So, in your initial comment you said we needed to keep it and figure out
 a way to not add it multiple times, and now you propose to remove it
 entirely. I'd really like to help with this, but I am constantly confused
 over what you think is the correct approach.

 You're right, I changed my mind, I'm sorry for being a pain and causing
 you work.

 I thought about ways to not include it multiple times, and there are ways,
 but there aren't any nice ways, whereas with the middleware approach it
 was easy, so I just don't think it is worth it, for the reasons given
 above.

 Cheers, thanks for persevering despite my vagaries.

-- 
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] #10554: Response.set_cookie should allow setting two cookies of the same name.

[Django]

#10554: Response.set_cookie should allow setting two cookies of the same name.
+---
  Reporter:  jdunck | Owner:  nobody
Status:  new| Milestone:
 Component:  HTTP handling  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by jdunck):

 OK, here's a plan for fix:

 Currently, Django's response.cookies is an instance of stdlib's
 Cookie.SimpleCookie(BaseCookie).

 BaseCookie is a subclass of dict, and so makes the assumption that there
 will be only one Morsel (that is, serializable cookie) per key.  Key is
 assumed to be string, because BaseCookie does things like .lower and
 .translate on it, and therefore, there can only be one morsel per cookie
 name.

 Here's the fix/hack: create a class which responds to the basestring
 methods, and takes all the HTTP-pertinent parameters (that is, name, path,
 domain, secure) into account for __cmp__ and __hash__.  Alter set_cookie
 to create an instance of that class as the key given to SimpleCookie.
 Respond to __str__ with just the cookie 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] #10555: Documentation version warning not showing up correctly in Firefox 3.0.7

[Django]

#10555: Documentation version warning not showing up correctly in Firefox 3.0.7
+---
  Reporter:  belm...@gmail.com  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by ramiro):

 I'm not seeing this, see attached image. Could you clean your browser
 cache and retry?

-- 
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] #10555: Documentation version warning not showing up correctly in Firefox 3.0.7

[Django]

#10555: Documentation version warning not showing up correctly in Firefox 3.0.7
+---
  Reporter:  belm...@gmail.com  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

Comment:

 That's no longer the CSS, try doing a + to clear out your
 cache.

-- 
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] #10555: Documentation version warning not showing up correctly in Firefox 3.0.7

[Django]

#10555: Documentation version warning not showing up correctly in Firefox 3.0.7
---+
 Reporter:  belm...@gmail.com  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Under Firefox 3.0.7 your documentation version blurb on top of the content
 does not appear correctly (bleeds into the header). Changing the CSS fixes
 this:

  h2.deck { margin-top:-.5em !important; margin-bottom:.6em; color:#487858;
 }

 to

  h2.deck { margin-top:.5em !important; margin-bottom:.6em; color:#487858;
 }

 I am unable to verify how that would look in other browsers 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] #9517: Minor: HTML showing up on documentation page

[Django]

#9517: Minor: HTML showing up on documentation page
--+-
  Reporter:  robballou| Owner:  nobody
Status:  new  | Milestone:  1.1   
 Component:  Django Web site  |   Version:  1.0   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Comment (by mboersma):

 I don't see any raw HTML displayed at
 http://docs.djangoproject.com/en/dev/ref/contrib/comments/ currently.  It
 doesn't appear there is anything to fix here now, unless I'm missing
 something.

-- 
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] #9193: Mac Documentation Issue

[Django]

#9193: Mac Documentation Issue
+---
  Reporter:  jlev   | Owner:  nobody
Status:  closed | Milestone:  1.1   
 Component:  Documentation  |   Version:  1.0   
Resolution:  invalid|  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by mboersma):

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

Comment:

 I find no mention of DYLD_LIBRARY_PATH or anything similar anywhere in
 django trunk or in 1.0.x.  Indeed, the discussion referenced does not
 mention Django.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #10554: Response.set_cookie should allow setting two cookies of the same name.

[Django]

#10554: Response.set_cookie should allow setting two cookies of the same name.
-+--
   Reporter:  jdunck |Owner:  nobody
 Status:  new|Milestone:
  Component:  HTTP handling  |  Version:  1.0   
   Keywords: |Stage:  Unreviewed
  Has_patch:  0  |   Needs_docs:  0 
Needs_tests:  0  |   Needs_better_patch:  0 
-+--
 Since cookies have domain and path properties, this is a sensible thing to
 do:

 {{{
 response.set_cookie('x', path='/foo/', expires=)
 response.set_cookie('x', path='/bar/', expires=)
 }}}

 It'd be nice if Django allowed this.  Sadly, I think this would mean
 moving away from Cookie.

-- 
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] #10553: Inconsistent use of "URLconf" in docs/topics/http/urls.txt

[Django]

#10553: Inconsistent use of "URLconf" in docs/topics/http/urls.txt
+---
  Reporter:  rduffield  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by rduffield):

  * needs_better_patch:  => 0
  * version:  1.0 => SVN
  * 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-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] #3237: [patch] CIDR in INTERNAL_IPS

[Django]

#3237: [patch] CIDR  in INTERNAL_IPS
--+-
  Reporter:  Jeremy Dunck   | Owner:  nobody  
 
Status:  reopened | Milestone:  
 
 Component:  Core framework   |   Version:  
 
Resolution:   |  Keywords:  CIDR 
INTERNAL_IPS
 Stage:  Design decision needed   | Has_patch:  0   
 
Needs_docs:  0|   Needs_tests:  0   
 
Needs_better_patch:  0|  
--+-
Changes (by kcarnold):

  * status:  closed => reopened
  * has_patch:  1 => 0
  * resolution:  wontfix =>

Comment:

 A simpler version (see http://www.djangosnippets.org/snippets/1380/)
 {{{
 from fnmatch import fnmatch
 class glob_list(list):
 def __contains__(self, key):
 for elt in self:
 if fnmatch(key, elt): return True
 return False

 INTERNAL_IPS = glob_list([
 '127.0.0.1',
 '18.85.*.*'
 ])
 }}}

 This is simple and useful enough that I'll entertain the thought of
 putting something like it in Django proper.

-- 
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] #6903: Go back to old change_list view after hitting save

[Django]

#6903: Go back to old change_list view after hitting save
-+--
  Reporter:  jarrow  | Owner:  ramiro  
Status:  new | Milestone:  1.1 beta
 Component:  django.contrib.admin|   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by mremolt):

 Replying to [comment:23 jarrow]:
 > > > I proposed to use the session to store the filters so that you don't
 pass your filters and search queries around whenever you pass the URL of
 an edit form to someone else. So I would use a hash of the data and use it
 as a key in the session. This key would then be passed around instead of
 the info. But this could be changed later, I don't think it would be
 backwards incompatible.
 > >
 > > I don't see, why it is a bad thing to be able to post the filter
 settings around with the url. I consider it a feature, to be able to copy
 a filtered admin changelist view URL into an email and post it to a
 colleague to show him exacly what I want him to notice. Using the session
 would also go against REST (no ambiguous URLs).
 > >
 > > Using URLs also automatically solves Malcolms request you mentioned.
 The admin start page just uses URLs without filter parameters as it always
 has.
 >
 > Sure. I totally agree :) What I was talking about was not the changelist
 view itself. Of course that stays like it is. With an URL that you can
 copy including the filters. What I meant was: While ''editing'' an item -
 coming from a filtered changelist - it might not be so obvious that if you
 copy the URL from the edit view and pass it to a fried he will be going
 back to your custom-filtered change list.

 Then I got your proposal wrong. I really don't think anyone wants to copy
 an URL from an edit page with filters enabled. Forget everything I said.
 (Note to self: READ, then post)

-- 
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] #10553: Inconsistent use of "URLconf" in docs/topics/http/urls.txt

[Django]

#10553: Inconsistent use of "URLconf" in docs/topics/http/urls.txt
---+
 Reporter:  rduffield  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 According to the guidelines for
 [http://docs.djangoproject.com/en/dev/internals/contributing/?from=olddocs
 #django-specific-terminology Django-specific terminology], a URL
 configuration is to be referred to as a '''URLconf''' and not
 '''URLConf''', as seen in a few places within this documentation topic.

-- 
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] #6903: Go back to old change_list view after hitting save

[Django]

#6903: Go back to old change_list view after hitting save
-+--
  Reporter:  jarrow  | Owner:  ramiro  
Status:  new | Milestone:  1.1 beta
 Component:  django.contrib.admin|   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by jarrow):

 > > I proposed to use the session to store the filters so that you don't
 pass your filters and search queries around whenever you pass the URL of
 an edit form to someone else. So I would use a hash of the data and use it
 as a key in the session. This key would then be passed around instead of
 the info. But this could be changed later, I don't think it would be
 backwards incompatible.
 >
 > I don't see, why it is a bad thing to be able to post the filter
 settings around with the url. I consider it a feature, to be able to copy
 a filtered admin changelist view URL into an email and post it to a
 colleague to show him exacly what I want him to notice. Using the session
 would also go against REST (no ambiguous URLs).
 >
 > Using URLs also automatically solves Malcolms request you mentioned. The
 admin start page just uses URLs without filter parameters as it always
 has.

 Sure. I totally agree :) What I was talking about was not the changelist
 view itself. Of course that stays like it is. With an URL that you can
 copy including the filters. What I meant was: While ''editing'' an item -
 coming from a filtered changelist - it might not be so obvious that if you
 copy the URL from the edit view and pass it to a fried he will be going
 back to your custom-filtered change list.

-- 
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] #10552: Built-in template fails "lowdly" with exception

[Django]

#10552: Built-in template fails "lowdly" with exception
-+--
 Reporter:  powerfox |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Template system  | Version:  SVN   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 length_is filter causes an exception if it's used with None intead of
 something that has len() method. According to docs this should never
 happen (tags and filters fails silently).

 {{{
 Exception Value:

 Caught an exception while rendering: object of type 'NoneType' has no
 len()

 Original Traceback (most recent call last):
   File "/usr/local/lib/python2.5/site-packages/django/template/debug.py",
 line 71, in render_node
 result = node.render(context)
   File "/usr/local/lib/python2.5/site-
 packages/django/template/defaulttags.py", line 250, in render
 value = bool_expr.resolve(context, True)
   File "/usr/local/lib/python2.5/site-
 packages/django/template/__init__.py", line 559, in resolve
 new_obj = func(obj, *arg_vals)
   File "/usr/local/lib/python2.5/site-
 packages/django/template/defaultfilters.py", line 523, in length_is
 return len(value) == int(arg)
 TypeError: object of type 'NoneType' has no len()

 }}}

-- 
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] #10197: Annotate breaks pickling of QuerySet

[Django]

#10197: Annotate breaks pickling of QuerySet
---+
  Reporter:  ja...@thelances.net   | Owner:  nobody 
   
Status:  new   | Milestone:  1.1
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:|  Keywords:  pickle, 
queryset, annotate
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by bthomas):

  * milestone:  1.1 beta => 1.1

Comment:

 This is just an ordinary bug, not a feature. I think it can miss the 1.1
 beta.

-- 
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] #9977: CSRFMiddleware needs template tag

[Django]

#9977: CSRFMiddleware needs template tag
-+--
  Reporter:  bthomas | Owner:  nobody
Status:  new | Milestone:
 Component:  Uncategorized   |   Version:  1.0   
Resolution:  |  Keywords:  csrf  
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  0 
Needs_better_patch:  1   |  
-+--
Comment (by bthomas):

 Replying to [comment:7 lukeplant]:
 > The 'noid' solution isn't really practical -- because it is manual, it
 means that templates for forms are not composable.  Personally, I would
 advocate removing the id attribute altogether.  The only use case for it
 is using the token in AJAX calls, but that shouldn't be necessary any
 longer (see the CSRF documentation).
 >
 > Removing the id attribute is slightly backwards incompatible, for the
 case of javascript that was relying on the behaviour of CsrfMiddleware to
 insert this attribute.  However, it was never documented that the
 CsrfMiddleware would do this, it was just a nice way to help AJAX apps to
 get around the middleware.  It's similar to the way that the admin
 HTML/CSS has changed - those changes can easily break custom admin
 templates or Javascript that was layered on top of the admin, but that's
 tough.  People are going to have to manually change stuff anyway to use
 the templatetag, so they should be aware of the change.
 >

 So, in your initial comment you said we needed to keep it and figure out a
 way to not add it multiple times, and now you propose to remove it
 entirely. I'd really like to help with this, but I am constantly confused
 over what you think is the correct approach.

-- 
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] #6903: Go back to old change_list view after hitting save

[Django]

#6903: Go back to old change_list view after hitting save
-+--
  Reporter:  jarrow  | Owner:  ramiro  
Status:  new | Milestone:  1.1 beta
 Component:  django.contrib.admin|   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by mremolt):

 * cc: mremolt (added)

Comment:

 Replying to [comment:21 jarrow]:
 > The idea was that you get an unfiltered list when you go to the
 changelist URL directly (not coming from an edit form of an entry).
 mawimawi's example code looks like he wants the filters to stay forever.
 To cite Malcolm "Yes, from the admin home page it should be a clean view."
 >
 > I proposed to use the session to store the filters so that you don't
 pass your filters and search queries around whenever you pass the URL of
 an edit form to someone else. So I would use a hash of the data and use it
 as a key in the session. This key would then be passed around instead of
 the info. But this could be changed later, I don't think it would be
 backwards incompatible.

 I don't see, why it is a bad thing to be able to post the filter settings
 around with the url. I consider it a feature, to be able to copy a
 filtered admin changelist view URL into an email and post it to a
 colleague to show him exacly what I want him to notice. Using the session
 would also go against REST (no ambiguous URLs).

 Using URLs also automatically solves Malcolms request you mentioned. The
 admin start page just uses URLs without filter parameters as it always
 has.

 Just my 5 cents.

-- 
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] #9977: CSRFMiddleware needs template tag

[Django]

#9977: CSRFMiddleware needs template tag
-+--
  Reporter:  bthomas | Owner:  nobody
Status:  new | Milestone:
 Component:  Uncategorized   |   Version:  1.0   
Resolution:  |  Keywords:  csrf  
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  0 
Needs_better_patch:  1   |  
-+--
Comment (by lukeplant):

 The 'noid' solution isn't really practical -- because it is manual, it
 means that templates for forms are not composable.  Personally, I would
 advocate removing the id attribute altogether.  The only use case for it
 is using the token in AJAX calls, but that shouldn't be necessary any
 longer (see the CSRF documentation).

 Removing the id attribute is slightly backwards incompatible, for the case
 of javascript that was relying on the behaviour of CsrfMiddleware to
 insert this attribute.  However, it was never documented that the
 CsrfMiddleware would do this, it was just a nice way to help AJAX apps to
 get around the middleware.  It's similar to the way that the admin
 HTML/CSS has changed - those changes can easily break custom admin
 templates or Javascript that was layered on top of the admin, but that's
 tough.  People are going to have to manually change stuff anyway to use
 the templatetag, so they should be aware of the change.

-- 
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] #10550: Broken link

[Django]

#10550: Broken link
---+
  Reporter:  Doug Carter   | Owner:  nobody
Status:  closed| Milestone:
 Component:  Uncategorized |   Version:  1.0   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

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

Comment:

 duplicate of #7933

-- 
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] #10222: [patch] Add line_merge to GEOS geometries under django.contrib.gis

[Django]

#10222: [patch] Add line_merge to GEOS geometries under django.contrib.gis
---+
  Reporter:  psmith| Owner:  jbronn
Status:  assigned  | Milestone:  1.1   
 Component:  GIS   |   Version:  1.0   
Resolution:|  Keywords:  geos linemerge
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Old description:

> In the C API of GEOS, GEOSLineMerge returns a new geometry that is the
> result of having merged contiguous line strings in a geometry collection
> or multi-line string geometry.
>
> Example:
>
> {{{
> >>> geomcoll = fromstr('MULTILINESTRING((1 1, 3 3), (3 3, 4 2))')
> >>> print geomcoll.line_merge()
> LINESTRING(1 1, 3 3, 4 2)
> }}}

New description:

 In the C API of GEOS, `GEOSLineMerge` returns a new geometry that is the
 result of having merged contiguous line strings in a geometry collection
 or multi-line string geometry.

 Example:

 {{{
 >>> geomcoll = fromstr('MULTILINESTRING((1 1, 3 3), (3 3, 4 2))')
 >>> print geomcoll.line_merge()
 LINESTRING(1 1, 3 3, 4 2)
 }}}

Comment (by jbronn):

 Now in the gis-1.1 mercurial repo, see
 [http://geodjango.org/hg/gis-1.1/rev/87b34dce202d].

 It is now a `merged` property that is only available on `LineString` and
 `MultiLineString` instances.

-- 
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] #10547: Delayed Loading Model Update Causes Recursive Errors

[Django]

#10547: Delayed Loading Model Update Causes Recursive Errors
---+
  Reporter:  megaman...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by megaman...@gmail.com):

 Also of note this error happened on Python 2.4

-- 
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] #10551: tiny bug in doc - form Textarea

[Django]

#10551: tiny bug in doc - form Textarea
--+-
 Reporter:  adrian_...@yahoo.com  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Documentation | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 In the page:

 http://docs.djangoproject.com/en/dev/topics/forms/modelforms/#overriding-
 the-default-field-types

 In the Field Types table near the top, it says a TextField is CharField
 with widget=Textarea.
 I think it should say widget=forms.Textarea.  Two places.

 (Not sure that it shouldn't be TextArea, but not worth breaking people's
 code to fix 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] #10550: Broken link

[Django]

#10550: Broken link
---+
  Reporter:  Doug Carter   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Uncategorized |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by bthomas):

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

Comment:

 That feature is new in the development version, so there isn't a 1.0 page.
 All new feature pages have the same problem (aggregation, etc).

-- 
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] #10550: Broken link

[Django]

#10550: Broken link
--+-
 Reporter:  Doug Carter   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Uncategorized | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 On page: http://docs.djangoproject.com/en/dev/howto/auth-remote-user
 /#howto-auth-remote-user

 The link: http://docs.djangoproject.com/en/1.0/howto/auth-remote-user/

 is broken.

-- 
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] #10549: BooleanField.formfield() does not handle choices correct. [PATCH]

[Django]

#10549: BooleanField.formfield() does not handle choices correct. [PATCH]
--+-
 Reporter:  sebastian_noack   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 If you have a BooleanField, with choices (as in the example below), the
 formfield() method always returns a TypedChoicesField, with a blank choice
 at the beginning. This is because of this entry is included always if the
 blank is True and BooleanFields are always blank=True. So we have to check
 for null instead of blank, when using BooleanFields, since the blank flag
 in the BooleanfField does not specify if the field can be empty in forms
 in contrast to other fields.

 {{{
 FLAG_CHOICES = (
 (0, _('No'),
 (1, _('Yes'),
 )

 class Foo(models.Model):
 flag = models.BooleanField(choices=FLAG_CHOICES)
 }}}

-- 
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] #10061: incorrect logout link in admin

[Django]

#10061: incorrect logout link in admin
---+
  Reporter:  lashni| Owner:  Alex
Status:  reopened  | Milestone:  1.1 
 Component:  django.contrib.admin  |   Version:  SVN 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

 * cc: sebastian.ra...@galileo-press.de (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] #8630: Improve the comments framework customizability

[Django]

#8630: Improve the comments framework customizability
--+-
  Reporter:  thejaswi_puthraya| Owner:  carljm  
   
Status:  closed   | Milestone:  
   
 Component:  django.contrib.comments  |   Version:  SVN 
   
Resolution:  fixed|  Keywords:  comments, 
customization
 Stage:  Accepted | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Changes (by carljm):

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

Comment:

 This is valid, but should get its own ticket.  Created #10548.

-- 
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] #10548: BaseCommentAbstractModel does not include is_public field needed for template tags

[Django]

#10548: BaseCommentAbstractModel does not include is_public field needed for
template tags
-+--
 Reporter:  carljm   |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  django.contrib.comments  | Version:  SVN   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 BaseCommentAbstractModel does not include is_public field, but
 BaseCommentNode (in templatetags/comments.py) filters on it.
 Documentation for custom comments says to inherit custom comment class
 from BaseCommentAbstractModel.  One of these things needs to be fixed.

 Originally reported by joshvanwyck in a comment on #8630.

-- 
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] #9977: CSRFMiddleware needs template tag

[Django]

#9977: CSRFMiddleware needs template tag
-+--
  Reporter:  bthomas | Owner:  nobody
Status:  new | Milestone:
 Component:  Uncategorized   |   Version:  1.0   
Resolution:  |  Keywords:  csrf  
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  0 
Needs_better_patch:  1   |  
-+--
Comment (by bthomas):

 I fixed the same issues as Rob in the latest patch, and it should no
 longer output the id attribute multiple times. The tag accepts a "noid"
 argument now, so you can choose which tag contains the id (by excluding it
 from the other tags).

-- 
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] #10547: Delayed Loading Model Update Causes Recursive Errors

[Django]

#10547: Delayed Loading Model Update Causes Recursive Errors
---+
  Reporter:  megaman...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by megaman...@gmail.com):

 I am running a stachmo store. One of the satchmo apps is called keyedcache
 eventually makes a call to cache.set(key, val, length) which sets off this
 whole chain.

-- 
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] #10547: Delayed Loading Model Update Causes Recursive Errors

[Django]

#10547: Delayed Loading Model Update Causes Recursive Errors
---+
  Reporter:  megaman...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
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

Old description:

> I don't really have much insight to this right now but here is the stack
> trace.
>
> File "/var/www/next_django/apps/django/core/cache/backends/filebased.py"
> in set
>   71. pickle.dump(value, f, pickle.HIGHEST_PROTOCOL)
> File "/var/www/next_django/apps/django/db/models/base.py" in __reduce__
>   352. return super(Model, self).__reduce__()
> File "/var/www/next_django/apps/django/db/models/base.py" in __reduce__
>   352. return super(Model, self).__reduce__()
> File "/var/www/next_django/apps/django/db/models/base.py" in __reduce__
>   352. return super(Model, self).__reduce__()
> File "/var/www/next_django/apps/django/db/models/base.py" in __reduce__

New description:

 I don't really have much insight to this right now but here is the stack
 trace.
 {{{
 File "/var/www/next_django/apps/django/core/cache/backends/filebased.py"
 in set
   71. pickle.dump(value, f, pickle.HIGHEST_PROTOCOL)
 File "/var/www/next_django/apps/django/db/models/base.py" in __reduce__
   352. return super(Model, self).__reduce__()
 File "/var/www/next_django/apps/django/db/models/base.py" in __reduce__
   352. return super(Model, self).__reduce__()
 File "/var/www/next_django/apps/django/db/models/base.py" in __reduce__
   352. return super(Model, self).__reduce__()
 File "/var/www/next_django/apps/django/db/models/base.py" in __reduce__
 }}}

Comment:

 Fixed formatting.  What is it you're trying to do that causes this error?

-- 
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] #10531: Choices template display example needed

[Django]

#10531: Choices template display example needed
+---
  Reporter:  paulbury   | Owner:  kc9ddi
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by kc9ddi):

  * owner:  anonymous => kc9ddi
  * status:  assigned => new

-- 
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] #10531: Choices template display example needed

[Django]

#10531: Choices template display example needed
+---
  Reporter:  paulbury   | Owner:  anonymous
Status:  assigned   | Milestone:   
 Component:  Uncategorized  |   Version:  1.0  
Resolution: |  Keywords:   
 Stage:  Unreviewed | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

  * owner:  nobody => anonymous
  * needs_better_patch:  => 0
  * status:  new => assigned
  * 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-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] #10547: Delayed Loading Model Update Causes Recursive Errors

[Django]

#10547: Delayed Loading Model Update Causes Recursive Errors
--+-
 Reporter:  megaman...@gmail.com  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I don't really have much insight to this right now but here is the stack
 trace.

 File "/var/www/next_django/apps/django/core/cache/backends/filebased.py"
 in set
   71. pickle.dump(value, f, pickle.HIGHEST_PROTOCOL)
 File "/var/www/next_django/apps/django/db/models/base.py" in __reduce__
   352. return super(Model, self).__reduce__()
 File "/var/www/next_django/apps/django/db/models/base.py" in __reduce__
   352. return super(Model, self).__reduce__()
 File "/var/www/next_django/apps/django/db/models/base.py" in __reduce__
   352. return super(Model, self).__reduce__()
 File "/var/www/next_django/apps/django/db/models/base.py" in __reduce__

-- 
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] #10546: "managed=True" should be "managed=False" in new doc note in r10089

[Django]

#10546: "managed=True" should be "managed=False" in new doc note in r10089
+---
  Reporter:  carljm | Owner:  nobody
Status:  new| Milestone:  1.1   
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * stage:  Unreviewed => Ready for checkin
  * needs_tests:  => 0
  * milestone:  => 1.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
-~--~~~~--~~--~--~---

Re: [Django] #8630: Improve the comments framework customizability

[Django]

#8630: Improve the comments framework customizability
--+-
  Reporter:  thejaswi_puthraya| Owner:  carljm  
   
Status:  reopened | Milestone:  
   
 Component:  django.contrib.comments  |   Version:  SVN 
   
Resolution:   |  Keywords:  comments, 
customization
 Stage:  Accepted | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Changes (by joshvanwyck):

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

Comment:

 Greetings,

 I'm trying to take advantage of the newest version of the django's
 customizable comments framework. I am  following all the documentation
 when I try and implement a simple comment system that has an additional
 field. I tried initially with a BooleanField, but have since resorted to
 trying to simply follow the example from the documentation provided.

 When I run it, I get the following error message:
 Caught an exception while rendering: Cannot resolve keyword 'is_public'
 into field. Choices are: content_type, id, object_pk, site, title

 I suspect that this is a bug or either mistaken documentation, as I'm
 assuming if I follow the example online character for character it should
 work.

 A couple of things I've found by digging through the code. If we extend
 the BaseCommentAbstractModel, how can we receive the Comment model's
 fields? Why does line 84 of templatetags/comments.py contain is_public =
 true. This field will only exist if we have extended the Comment model but
 this isn't an option as we are supposed to extend the
 BaseCommentAbstractModel.

 Also the unit testing doesn't seem to test the rendering which is where
 the problems seem to be occurring.

 Maybe I'm completely off here, this is my first time posting any comments
 so if I have broken any posting rules please let me know.

 Thanks for your work on this portion.

 Josh

-- 
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] #10529: Generic Inline fails (unexpected keyword argument `prefix`)

[Django]

#10529: Generic Inline fails (unexpected keyword argument `prefix`)
-+--
  Reporter:  leitjohn| Owner:  leitjohn
Status:  closed  | Milestone:  
 Component:  Forms   |   Version:  SVN 
Resolution:  invalid |  Keywords:  
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by leitjohn):

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

Comment:

 This was my mistake, thanks for pointing that out to me.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #10546: "managed=True" should be "managed=False" in new doc note in r10089

[Django]

#10546: "managed=True" should be "managed=False" in new doc note in r10089
---+
 Reporter:  carljm |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 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] #10541: cannot save file from a pipe

[Django]

#10541: cannot save file from a pipe
---+
  Reporter:  liangent  | Owner:  nobody
Status:  new   | Milestone:
 Component:  File uploads/storage  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by liangent):

 the field was left blank after saving

-- 
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] #10541: cannot save file from a pipe

[Django]

#10541: cannot save file from a pipe
---+
  Reporter:  liangent  | Owner:  nobody
Status:  new   | Milestone:
 Component:  File uploads/storage  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by jacob):

 Please clarify what you mean be "cannot be saved" -- is there an error? If
 so, what is it?

-- 
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] #9447: ifequal should be chainable(and,or)

[Django]

#9447: ifequal should be chainable(and,or)
-+--
  Reporter:  hybrid.ba...@gmail.com  | Owner:  nobody
Status:  new | Milestone:
 Component:  Template system |   Version:  1.0   
Resolution:  |  Keywords:  ifequal,and,or
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by KovaK):

 What is it going to 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-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] #5691: Add the active language to generate the cache key

[Django]

#5691: Add the active language to generate the cache key
-+--
  Reporter:  aa...@apsl.net  | Owner:  aaloy
Status:  assigned| Milestone:   
 Component:  Cache system|   Version:  SVN  
Resolution:  |  Keywords:  cache i18n jgd-blackboard
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by jdunck):

  * keywords:  cache i18n => cache i18n jgd-blackboard

-- 
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] #10540: Remove small documentation redundancy redundancy

[Django]

#10540: Remove small documentation redundancy redundancy
+---
  Reporter:  llimllib   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by timo):

  * needs_better_patch:  => 0
  * has_patch:  0 => 1
  * stage:  Unreviewed => Ready for checkin
  * 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-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] #10543: Something like Jobeet from Symfony

[Django]

#10543: Something like Jobeet from Symfony
+---
  Reporter:  jorgelb| Owner:  nobody 
Status:  closed | Milestone: 
 Component:  Documentation  |   Version:  1.0
Resolution:  invalid|  Keywords:  tutorial, documentation
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by russellm):

 This isn't a simple help request. It's a request for a particular type of
 documentation.

 However, I agree that the ticket is invalid. Django already has
 documentation of the development of a fully functional web site, built
 from scratch - it's the tutorial. Documenting "all the capabilities of the
 framework" is a bit of a hard ask - Django has a lot of capabilities, and
 getting all of them into a single tutorial is going to be difficult.

 The tutorial could certainly be expanded, covering more parts of the
 development lifecycle (testing, deployment etc). However, a generic "make
 the docs better" ticket doesn't really help. We need specific suggestions
 - at the very least, a set of bullet points of what should be included.
 You get bonus points if you provide an initial draft.

 If you have a specific suggestion for a tutorial that, feel free to open a
 ticket describing the improvement you would like to see. Don't forget to
 search the ticket database to see if someone has already requested the
 same thing - there are a number of specific documentation suggestions that
 are already in Trac.

-- 
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] r10091 - django/trunk/django/db/models

[noreply]

Author: mtredinnick
Date: 2009-03-19 04:43:45 -0500 (Thu, 19 Mar 2009)
New Revision: 10091

Modified:
   django/trunk/django/db/models/query.py
Log:
Typo fix for an error path in r100090.

Modified: django/trunk/django/db/models/query.py
===
--- django/trunk/django/db/models/query.py  2009-03-19 09:06:04 UTC (rev 
10090)
+++ django/trunk/django/db/models/query.py  2009-03-19 09:43:45 UTC (rev 
10091)
@@ -609,7 +609,7 @@
 method and that are not already specified as deferred are loaded
 immediately when the queryset is evaluated.
 """
-if fields == [None]:
+if fields == (None,):
 # Can only pass None to defer(), not only(), as the rest option.
 # That won't stop people trying to do this, so let's be explicit.
 raise TypeError("Cannot pass None as an argument to only().")


--~--~-~--~~~---~--~~
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] #10545: Developing custom tag - setting context is missing a limitation

[Django]

#10545: Developing custom tag - setting context is missing a limitation
+---
  Reporter:  yaniv.ha...@gmail.com  | Owner:  nobody
  
Status:  new| Milestone:
  
 Component:  Documentation  |   Version:  1.0   
  
Resolution: |  Keywords:  custom template 
tags
 Stage:  Accepted   | Has_patch:  0 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

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

Comment:

 It should certainly be mentioned, you're right about. However the
 behaviour is intentional. It provides a scope for the variables so that
 they don't clash with other things. Yes, I realise there are cases where
 people sometimes want a more extensive visibility scope, so no need to
 post that you have such a case. We have scoping, though, and it's relied
 upon in a lot of places, so I wouldn't expect it to change.

-- 
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] r10090 - in django/trunk: django/db/models django/db/models/sql docs/ref/models tests/modeltests tests/modeltests/defer tests/regressiontests/queries

[noreply]

Author: mtredinnick
Date: 2009-03-19 04:06:04 -0500 (Thu, 19 Mar 2009)
New Revision: 10090

Added:
   django/trunk/tests/modeltests/defer/
   django/trunk/tests/modeltests/defer/__init__.py
   django/trunk/tests/modeltests/defer/models.py
Modified:
   django/trunk/django/db/models/base.py
   django/trunk/django/db/models/manager.py
   django/trunk/django/db/models/options.py
   django/trunk/django/db/models/query.py
   django/trunk/django/db/models/query_utils.py
   django/trunk/django/db/models/sql/query.py
   django/trunk/docs/ref/models/querysets.txt
   django/trunk/tests/regressiontests/queries/models.py
Log:
Fixed #5420 -- Added support for delayed loading of model fields.

In extreme cases, some fields are expensive to load from the database
(e.g. GIS fields requiring conversion, or large text fields). This
commit adds defer() and only() methods to querysets that allow the
caller to specify which fields should not be loaded unless they are
accessed.

Modified: django/trunk/django/db/models/base.py
===
--- django/trunk/django/db/models/base.py   2009-03-19 09:04:19 UTC (rev 
10089)
+++ django/trunk/django/db/models/base.py   2009-03-19 09:06:04 UTC (rev 
10090)
@@ -12,7 +12,8 @@
 from django.core.exceptions import ObjectDoesNotExist, 
MultipleObjectsReturned, FieldError
 from django.db.models.fields import AutoField, FieldDoesNotExist
 from django.db.models.fields.related import OneToOneRel, ManyToOneRel, 
OneToOneField
-from django.db.models.query import delete_objects, Q, CollectedObjects
+from django.db.models.query import delete_objects, Q
+from django.db.models.query_utils import CollectedObjects, DeferredAttribute
 from django.db.models.options import Options
 from django.db import connection, transaction, DatabaseError
 from django.db.models import signals
@@ -235,6 +236,7 @@
 
 class Model(object):
 __metaclass__ = ModelBase
+_deferred = False
 
 def __init__(self, *args, **kwargs):
 signals.pre_init.send(sender=self.__class__, args=args, kwargs=kwargs)
@@ -271,6 +273,13 @@
 for field in fields_iter:
 is_related_object = False
 if kwargs:
+# This slightly odd construct is so that we can access any
+# data-descriptor object (DeferredAttribute) without triggering
+# its __get__ method.
+if (field.attname not in kwargs and
+isinstance(self.__class__.__dict__.get(field.attname), 
DeferredAttribute)):
+# This field will be populated on request.
+continue
 if isinstance(field.rel, ManyToOneRel):
 try:
 # Assume object instance was passed in.
@@ -332,6 +341,31 @@
 def __hash__(self):
 return hash(self._get_pk_val())
 
+def __reduce__(self):
+"""
+Provide pickling support. Normally, this just dispatches to Python's
+standard handling. However, for models with deferred field loading, we
+need to do things manually, as they're dynamically created classes and
+only module-level classes can be pickled by the default path.
+"""
+if not self._deferred:
+return super(Model, self).__reduce__()
+data = self.__dict__
+defers = []
+pk_val = None
+for field in self._meta.fields:
+if isinstance(self.__class__.__dict__.get(field.attname),
+DeferredAttribute):
+defers.append(field.attname)
+if pk_val is None:
+# The pk_val and model values are the same for all
+# DeferredAttribute classes, so we only need to do this
+# once.
+obj = self.__class__.__dict__[field.attname]
+pk_val = obj.pk_value
+model = obj.model_ref()
+return (model_unpickle, (model, pk_val, defers), data)
+
 def _get_pk_val(self, meta=None):
 if not meta:
 meta = self._meta
@@ -591,6 +625,15 @@
 class Empty(object):
 pass
 
+def model_unpickle(model, pk_val, attrs):
+"""
+Used to unpickle Model subclasses with deferred fields.
+"""
+from django.db.models.query_utils import deferred_class_factory
+cls = deferred_class_factory(model, pk_val, attrs)
+return cls.__new__(cls)
+model_unpickle.__safe_for_unpickle__ = True
+
 if sys.version_info < (2, 5):
 # Prior to Python 2.5, Exception was an old-style class
 def subclass_exception(name, parent, unused):

Modified: django/trunk/django/db/models/manager.py
===
--- django/trunk/django/db/models/manager.py2009-03-19 09:04:19 UTC (rev 
10089)
+++ django/trunk/django/db/models/manager.py2009-03-19 09:06:04 UTC (rev 
10090)
@@ -167,6 +167,12 @@
 def reverse(self, *arg

[Django] #10545: Developing custom tag - setting context is missing a limitation

[Django]

#10545: Developing custom tag - setting context is missing a limitation
---+
 Reporter:  yaniv.ha...@gmail.com  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords:  custom template tags   |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 In the documentation of SETTING A VARIABLE IN THE CONTEXT
 ([http://docs.djangoproject.com/en/dev/howto/custom-template-
 tags/#setting-a-variable-in-the-context]) it is not mentioned that any
 variable set to the context will only be available in the same BLOCK part
 of the template in which it was assigned.
 This limitation needs to be mentioned in the docs and hopefully solved in
 a future version.

-- 
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] r10089 - in django/trunk/docs: ref/models topics/db

[noreply]

Author: mtredinnick
Date: 2009-03-19 04:04:19 -0500 (Thu, 19 Mar 2009)
New Revision: 10089

Modified:
   django/trunk/docs/ref/models/options.txt
   django/trunk/docs/topics/db/models.txt
Log:
Added some documentation explaining "managed=False" vs. "proxy=True".

These features look similar, but they're not identical. They can't be merged
into one (without requiring at least two Meta parameters anyway), so we've made
them have APIs that match their natural use-cases most easily.

Anyway, the documentation explains both the details and gives some simple to
follow rules.

Modified: django/trunk/docs/ref/models/options.txt
===
--- django/trunk/docs/ref/models/options.txt2009-03-18 16:55:59 UTC (rev 
10088)
+++ django/trunk/docs/ref/models/options.txt2009-03-19 09:04:19 UTC (rev 
10089)
@@ -99,6 +99,10 @@
 For tests involving models with ``managed=False``, it's up to you to ensure
 the correct tables are created as part of the test setup.
 
+If you're interested in changing the Python-level behaviour of a model class,
+you *could* use ``managed=True`` and create a copy of an existing model.
+However, there's a better approach for that situation: :ref:`proxy-models`.
+
 ``order_with_respect_to``
 -
 

Modified: django/trunk/docs/topics/db/models.txt
===
--- django/trunk/docs/topics/db/models.txt  2009-03-18 16:55:59 UTC (rev 
10088)
+++ django/trunk/docs/topics/db/models.txt  2009-03-19 09:04:19 UTC (rev 
10089)
@@ -1117,6 +1117,48 @@
 You probably won't need to do this very often, but, when you do, it's
 possible.
 
+Differences between proxy inheritance and  unmanaged models
+~~~
+
+Proxy model inheritance might look fairly similar to creating an unmanaged
+model, using the :attr:`~django.db.models.Options.managed` attribute on a
+model's ``Meta`` class. The two alternatives are not quite the same and it's
+worth considering which one you should use.
+
+One difference is that you can (and, in fact, must unless you want an empty
+model) specify model fields on models with ``Meta.managed=False``. You could,
+with careful setting of :attr:`Meta.db_table
+` create an unmanaged model that shadowed
+an existing model and add Python methods to it. However, that would be very
+repetitive and fragile as you need to keep both copies synchronized if you
+make any changes.
+
+The other difference that is more important for proxy models, is how model
+managers are handled. Proxy models are intended to behave exactly like the
+model they are proxying for. So they inherit the parent model's managers,
+including the default manager. In the normal multi-table model inheritance
+case, children do not inherit managers from their parents as the custom
+managers aren't always appropriate when extra fields are involved. The
+:ref:`manager documentation ` has more
+details about this latter case.
+
+When these two features were implemented, attempts were made to squash them
+into a single option. It turned out that interactions with inheritance, in
+general, and managers, in particular, made the API very complicated and
+potentially difficult to understand and use. It turned out that two options
+were needed in any case, so the current separation arose.
+
+So, the general rules are:
+
+1. If you are mirroring an existing model or database table and don't want
+   all the original database table columns, use ``Meta.managed=False``.
+   That option is normally useful for modeling database views and tables
+   not under the control of Django.
+2. If you are wanting to change the Python-only behavior of a model, but
+   keep all the same fields as in the original, use ``Meta.proxy=True``.
+   This sets things up so that the proxy model is an exact copy of the
+   storage structure of the original model when data is saved.
+
 Multiple inheritance
 
 


--~--~-~--~~~---~--~~
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] #10544: Saving ModelForm to update exisitng record generates No {model} matches the given query.

[Django]

#10544: Saving ModelForm to update exisitng record generates No {model} matches 
the
given query.
+---
  Reporter:  mcwong644  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

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

Old description:

> #models.py
>
> class Publisher(models.Model):
>
> name = models.CharField(max_length=30)
>
> address = models.CharField(max_length=50)
>
> city = models.CharField(max_length=60)
>
> state_province = models.CharField(max_length=30)
>
> country = models.CharField(max_length=50)
>
> website = models.URLField()
>
> def __unicode__(self):
>
> return self.name
>
> class Meta:
>
> ordering = ["name"]
>

> class Author(models.Model):
>
> first_name = models.CharField(max_length=30)
>
> last_name = models.CharField(max_length=40)
>
> email = models.EmailField(blank=True, verbose_name='e-mail')
>
> objects = models.Manager()
>
> sel_objects=AuthorManager()
>
> def __unicode__(self):
>
> return self.first_name+' '+ self.last_name
>

> class Book(models.Model):
>
> title = models.CharField(max_length=100)
>
> authors = models.ManyToManyField(Author)
>
> publisher = models.ForeignKey(Publisher)
>
> publication_date = models.DateField(blank=True, null=True)
>
> num_pages = models.IntegerField(blank=True, null=True)
>
> objects = models.Manager()
>
> bookobjects = BookManager()
>
> wong = WongAuthor()
>

> class BookForm(ModelForm):
>
> class Meta:
>
> model = Book
>

> #view.py
> def authorcontactupd(request,id):
> if request.method == 'POST':
> a=Author.objects.get(pk=int(id))
> form = AuthorForm(request.POST, instance=a)
> if form.is_valid():
> form.save()
> return HttpResponseRedirect('/contact/created')
> else:
> a=Author.objects.get(pk=int(id))
> form = AuthorForm(instance=a)
> return render_to_response('author_form.html', {'form': form})
>

> # error
>

> Page not found (404)
> Request Method: POST
> Request URL:http://127.0.0.1:8000/books/bookupd/
>
> No Publisher matches the given query.
>
> You're seeing this error because you have DEBUG = True in your Django
> settings file. Change that to False, and Django will display a standard
> 404 page.

New description:

 {{{
 #!python
 #models.py

 class Publisher(models.Model):
 name = models.CharField(max_length=30)
 address = models.CharField(max_length=50)
 city = models.CharField(max_length=60)
 state_province = models.CharField(max_length=30)
 country = models.CharField(max_length=50)
 website = models.URLField()

 def __unicode__(self):
 return self.name

 class Meta:
 ordering = ["name"]

 class Author(models.Model):
 first_name = models.CharField(max_length=30)
 last_name = models.CharField(max_length=40)
 email = models.EmailField(blank=True, verbose_name='e-mail')
 objects = models.Manager()
 sel_objects=AuthorManager()

 def __unicode__(self):
 return self.first_name+' '+ self.last_name

 class Book(models.Model):
 title = models.CharField(max_length=100)
 authors = models.ManyToManyField(Author)
 publisher = models.ForeignKey(Publisher)
 publication_date = models.DateField(blank=True, null=True)
 num_pages = models.IntegerField(blank=True, null=True)
 objects = models.Manager()
 bookobjects = BookManager()
 wong = WongAuthor()

 class BookForm(ModelForm):
 class Meta:
 model = Book

 #view.py
 def authorcontactupd(request,id):
 if request.method == 'POST':
 a=Author.objects.get(pk=int(id))
 form = AuthorForm(request.POST, instance=a)
 if form.is_valid():
 form.save()
 return HttpResponseRedirect('/contact/created')
 else:
 a=Author.objects.get(pk=int(id))
 form = AuthorForm(instance=a)
 return render_to_response('author_form.html', {'form': form})
 }}}

 Produces this error
 {{{
 Page not found (404)
 Request Method: POST
 Request URL:http://127.0.0.1:8000/books/bookupd/

 No Publisher matches the given query.

 You're seeing this error because you have DEBUG = True in your Django
 settings file. Change that to False, and Django will display a standard
 404 page.
 }}}

Comment:

 This looks like a problem in your code, r

Re: [Django] #10543: Something like Jobeet from Symfony

[Django]

#10543: Something like Jobeet from Symfony
+---
  Reporter:  jorgelb| Owner:  nobody 
Status:  closed | Milestone: 
 Component:  Documentation  |   Version:  1.0
Resolution:  invalid|  Keywords:  tutorial, documentation
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by anih):

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

Comment:

 Trac isn't for help, use [http://groups.google.com/group/django-users/
 django-users] group 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
-~--~~~~--~~--~--~---

[Django] #10544: Saving ModelForm to update exisitng record generates No {model} matches the given query.

[Django]

#10544: Saving ModelForm to update exisitng record generates No {model} matches 
the
given query.
---+
 Reporter:  mcwong644  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 #models.py

 class Publisher(models.Model):

 name = models.CharField(max_length=30)

 address = models.CharField(max_length=50)

 city = models.CharField(max_length=60)

 state_province = models.CharField(max_length=30)

 country = models.CharField(max_length=50)

 website = models.URLField()

 def __unicode__(self):

 return self.name

 class Meta:

 ordering = ["name"]


 class Author(models.Model):

 first_name = models.CharField(max_length=30)

 last_name = models.CharField(max_length=40)

 email = models.EmailField(blank=True, verbose_name='e-mail')

 objects = models.Manager()

 sel_objects=AuthorManager()

 def __unicode__(self):

 return self.first_name+' '+ self.last_name


 class Book(models.Model):

 title = models.CharField(max_length=100)

 authors = models.ManyToManyField(Author)

 publisher = models.ForeignKey(Publisher)

 publication_date = models.DateField(blank=True, null=True)

 num_pages = models.IntegerField(blank=True, null=True)

 objects = models.Manager()

 bookobjects = BookManager()

 wong = WongAuthor()


 class BookForm(ModelForm):

 class Meta:

 model = Book


 #view.py
 def authorcontactupd(request,id):
 if request.method == 'POST':
 a=Author.objects.get(pk=int(id))
 form = AuthorForm(request.POST, instance=a)
 if form.is_valid():
 form.save()
 return HttpResponseRedirect('/contact/created')
 else:
 a=Author.objects.get(pk=int(id))
 form = AuthorForm(instance=a)
 return render_to_response('author_form.html', {'form': form})


 # error


 Page not found (404)
 Request Method: POST
 Request URL:http://127.0.0.1:8000/books/bookupd/

 No Publisher matches the given query.

 You're seeing this error because you have DEBUG = True in your Django
 settings file. Change that to False, and Django will display a standard
 404 page.

-- 
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] #10543: Something like Jobeet from Symfony

[Django]

#10543: Something like Jobeet from Symfony
-+--
 Reporter:  jorgelb  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Documentation| Version:  1.0   
 Keywords:  tutorial, documentation  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 Hi some time ago in a project where I have been working, we have been
 using the Symfony framework (PHP).

 Looking more closely I noticed that this framework has an excellent
 documentation, and also have documented the development of a fully
 function Web Site build from the scratch, demonstrating all the
 capabilities of the frameworks.

 Would be good to have something similar for Django, that demonstrates how
 to build a website from scratch using our favorite tools

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