Re: [Django] #17419: JSON template tag

[Django]

#17419: JSON template tag
---+---
 Reporter:  lau|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Template system|  Version:  1.4-alpha-1
 Severity:  Normal |   Resolution:
 Keywords:  json template tag  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+---
Changes (by carbonXT):

 * needs_docs:  1 => 0
 * version:  1.3 => 1.4-alpha-1
 * needs_tests:  1 => 0


Comment:

 I've uploaded a patch that applies cleanly to trunk that contains the new
 filter, tests, and documentation.

 Would be great to get this into 1.4 - let me know if you need any
 additions/changes in order to accept it. Thanks.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Changeset] r17341 - in django/trunk: django/db/backends/mysql docs/releases docs/topics/db tests/regressiontests/transactions_regress

[noreply]

Author: ramiro
Date: 2012-01-04 16:45:31 -0800 (Wed, 04 Jan 2012)
New Revision: 17341

Modified:
   django/trunk/django/db/backends/mysql/base.py
   django/trunk/docs/releases/1.4.txt
   django/trunk/docs/topics/db/transactions.txt
   django/trunk/tests/regressiontests/transactions_regress/tests.py
Log:
Added support for savepoints to the MySQL DB backend.

MySQL provides the savepoint functionality starting with version 5.0.3
when using the MyISAM storage engine.

Thanks lamby for the report and patch.

Fixes #15507.

Modified: django/trunk/django/db/backends/mysql/base.py
===
--- django/trunk/django/db/backends/mysql/base.py   2012-01-04 23:55:34 UTC 
(rev 17340)
+++ django/trunk/django/db/backends/mysql/base.py   2012-01-05 00:45:31 UTC 
(rev 17341)
@@ -150,18 +150,28 @@
 requires_explicit_null_ordering_when_grouping = True
 allows_primary_key_0 = False
 
+def __init__(self, connection):
+super(DatabaseFeatures, self).__init__(connection)
+self._storage_engine = None
+
+def _mysql_storage_engine(self):
+"Internal method used in Django tests. Don't rely on this from your 
code"
+if self._storage_engine is None:
+cursor = self.connection.cursor()
+cursor.execute('CREATE TABLE INTROSPECT_TEST (X INT)')
+# This command is MySQL specific; the second column
+# will tell you the default table type of the created
+# table. Since all Django's test tables will have the same
+# table type, that's enough to evaluate the feature.
+cursor.execute("SHOW TABLE STATUS WHERE Name='INTROSPECT_TEST'")
+result = cursor.fetchone()
+cursor.execute('DROP TABLE INTROSPECT_TEST')
+self._storage_engine = result[1]
+return self._storage_engine
+
 def _can_introspect_foreign_keys(self):
 "Confirm support for introspected foreign keys"
-cursor = self.connection.cursor()
-cursor.execute('CREATE TABLE INTROSPECT_TEST (X INT)')
-# This command is MySQL specific; the second column
-# will tell you the default table type of the created
-# table. Since all Django's test tables will have the same
-# table type, that's enough to evaluate the feature.
-cursor.execute("SHOW TABLE STATUS WHERE Name='INTROSPECT_TEST'")
-result = cursor.fetchone()
-cursor.execute('DROP TABLE INTROSPECT_TEST')
-return result[1] != 'MyISAM'
+return self._mysql_storage_engine() != 'MyISAM'
 
 class DatabaseOperations(BaseDatabaseOperations):
 compiler_module = "django.db.backends.mysql.compiler"
@@ -285,6 +295,15 @@
 items_sql = "(%s)" % ", ".join(["%s"] * len(fields))
 return "VALUES " + ", ".join([items_sql] * num_values)
 
+def savepoint_create_sql(self, sid):
+return "SAVEPOINT %s" % sid
+
+def savepoint_commit_sql(self, sid):
+return "RELEASE SAVEPOINT %s" % sid
+
+def savepoint_rollback_sql(self, sid):
+return "ROLLBACK TO SAVEPOINT %s" % sid
+
 class DatabaseWrapper(BaseDatabaseWrapper):
 vendor = 'mysql'
 operators = {
@@ -354,6 +373,8 @@
 self.connection = Database.connect(**kwargs)
 self.connection.encoders[SafeUnicode] = 
self.connection.encoders[unicode]
 self.connection.encoders[SafeString] = 
self.connection.encoders[str]
+self.features.uses_savepoints = \
+self.get_server_version() >= (5, 0, 3)
 connection_created.send(sender=self.__class__, connection=self)
 cursor = self.connection.cursor()
 if new_connection:

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2012-01-04 23:55:34 UTC (rev 17340)
+++ django/trunk/docs/releases/1.4.txt  2012-01-05 00:45:31 UTC (rev 17341)
@@ -553,6 +553,9 @@
   password reset mechanism and making it available is now much easier. For
   details, see :ref:`auth_password_reset`.
 
+* The MySQL database backend can now make use of the savepoint feature
+  implemented by MySQL version 5.0.3 or newer with the InnoDB storage engine.
+
 Backwards incompatible changes in 1.4
 =
 

Modified: django/trunk/docs/topics/db/transactions.txt
===
--- django/trunk/docs/topics/db/transactions.txt2012-01-04 23:55:34 UTC 
(rev 17340)
+++ django/trunk/docs/topics/db/transactions.txt2012-01-05 00:45:31 UTC 
(rev 17341)
@@ -225,12 +225,15 @@
 Savepoints
 ==
 
-A savepoint is a marker within a transaction that enables you to roll back
-part of a transaction, rather than the full transaction. Savepoints are
-available to the PostgreSQL 8 and Oracle backends. Other backends will
-provide the savepoint functions, but they are e

Re: [Django] #15507: Savepoint support for MySQL backend

[Django]

#15507: Savepoint support for MySQL backend
-+-
 Reporter:  lamby|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by ramiro):

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


Comment:

 In [17341]:
 {{{
 #!CommitTicketReference repository="" revision="17341"
 Added support for savepoints to the MySQL DB backend.

 MySQL provides the savepoint functionality starting with version 5.0.3
 when using the MyISAM storage engine.

 Thanks lamby for the report and patch.

 Fixes #15507.
 }}}

-- 
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] r17340 - in django/trunk: django/core/management docs/ref tests/regressiontests/admin_scripts

[noreply]

Author: carljm
Date: 2012-01-04 15:55:34 -0800 (Wed, 04 Jan 2012)
New Revision: 17340

Modified:
   django/trunk/django/core/management/templates.py
   django/trunk/docs/ref/django-admin.txt
   django/trunk/tests/regressiontests/admin_scripts/tests.py
Log:
Fixed #17503 -- A destination directory passed to startproject or startapp as 
optional second argument is now reused as the project/app directory, rather 
than a new project/app directory created within it. Refs #17042.

Modified: django/trunk/django/core/management/templates.py
===
--- django/trunk/django/core/management/templates.py2012-01-04 18:35:45 UTC 
(rev 17339)
+++ django/trunk/django/core/management/templates.py2012-01-04 23:55:34 UTC 
(rev 17340)
@@ -73,15 +73,14 @@
 
 # if some directory is given, make sure it's nicely expanded
 if target is None:
-target = os.getcwd()
+top_dir = path.join(os.getcwd(), name)
+try:
+os.makedirs(top_dir)
+except OSError, e:
+raise CommandError(e)
 else:
-target = path.expanduser(target)
+top_dir = path.expanduser(target)
 
-top_dir = path.join(target, name)
-try:
-os.makedirs(top_dir)
-except OSError, e:
-raise CommandError(e)
 
 extensions = tuple(
 handle_extensions(options.get('extensions'), ignored=()))

Modified: django/trunk/docs/ref/django-admin.txt
===
--- django/trunk/docs/ref/django-admin.txt  2012-01-04 18:35:45 UTC (rev 
17339)
+++ django/trunk/docs/ref/django-admin.txt  2012-01-04 23:55:34 UTC (rev 
17340)
@@ -922,13 +922,13 @@
 name is given, the app directory will be created in the current working
 directory.
 
-If the optional destination is provided, Django will create the new project
-directory in that directory. You can use '.' to denote the current working
-directory.
+If the optional destination is provided, Django will use that existing
+directory rather than creating a new one. You can use '.' to denote the current
+working directory.
 
 For example::
 
-django-admin.py startapp myapp /Users/jezdez/Code
+django-admin.py startapp myapp /Users/jezdez/Code/myapp
 
 .. versionadded:: 1.4
 .. django-admin-option:: --template
@@ -984,20 +984,20 @@
 .. versionchanged:: 1.4
 
 By default, the new directory contains ``manage.py`` and a project package
-(containing ``settings.py`` file and other project template files).
-See the `template source`_ for details.
+(containing a ``settings.py`` and other files).  See the `template source`_ for
+details.
 
 If only the project name is given, both the project directory and project
 package will be named  and the project directory
 will be created in the current working directory.
 
-If the optional destination is provided, Django will create the new project
-directory in that directory. You can use '.' to denote the current working
-directory.
+If the optional destination is provided, Django will use that existing
+directory as the project directory, and create ``manage.py`` and the project
+package within it. You can use '.' to denote the current working directory.
 
 For example::
 
-django-admin.py startproject myproject /Users/jezdez/Code
+django-admin.py startproject myproject /Users/jezdez/Code/myproject_repo
 
 .. versionadded:: 1.4
 

Modified: django/trunk/tests/regressiontests/admin_scripts/tests.py
===
--- django/trunk/tests/regressiontests/admin_scripts/tests.py   2012-01-04 
18:35:45 UTC (rev 17339)
+++ django/trunk/tests/regressiontests/admin_scripts/tests.py   2012-01-04 
23:55:34 UTC (rev 17340)
@@ -1404,17 +1404,17 @@
 "Make sure the startproject management command creates a project in a 
specific directory"
 args = ['startproject', 'testproject', 'othertestproject']
 testproject_dir = os.path.join(test_dir, 'othertestproject')
+os.mkdir(testproject_dir)
 
 out, err = self.run_django_admin(args)
 self.addCleanup(shutil.rmtree, testproject_dir)
 self.assertNoOutput(err)
-self.assertTrue(os.path.isdir(os.path.join(testproject_dir, 
'testproject')))
-self.assertTrue(os.path.exists(os.path.join(testproject_dir, 
'testproject', 'manage.py')))
+self.assertTrue(os.path.exists(os.path.join(testproject_dir, 
'manage.py')))
 
 # running again..
 out, err = self.run_django_admin(args)
 self.assertNoOutput(out)
-self.assertOutput(err, "File exists")
+self.assertOutput(err, "already exists")
 
 def test_custom_project_template(self):
 "Make sure the startproject management command is able to use a 
different project template"
@@ -1452,6 +1452,19 @@
 self.assertTrue(os.path.isdir(testproject_dir))

Re: [Django] #17042: allow startproject, startapp to write into existing directory or a specified directory

[Django]

#17042: allow startproject, startapp to write into existing directory or a
specified directory
-+-
 Reporter:  ptone|Owner:  jezdez
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  SVN
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by carljm):

 In [17340]:
 {{{
 #!CommitTicketReference repository="" revision="17340"
 Fixed #17503 -- A destination directory passed to startproject or startapp
 as optional second argument is now reused as the project/app directory,
 rather than a new project/app directory created within it. Refs #17042.
 }}}

-- 
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] #17503: startproject can't create new project directly in current working directory

[Django]

#17503: startproject can't create new project directly in current working 
directory
-+-
 Reporter:  carljm   |Owner:  carljm
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.3
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

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


Comment:

 In [17340]:
 {{{
 #!CommitTicketReference repository="" revision="17340"
 Fixed #17503 -- A destination directory passed to startproject or startapp
 as optional second argument is now reused as the project/app directory,
 rather than a new project/app directory created within it. Refs #17042.
 }}}

-- 
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] #17503: startproject can't create new project directly in current working directory

[Django]

#17503: startproject can't create new project directly in current working 
directory
-+-
   Reporter:  carljm |  Owner:  carljm
   Type:  Bug| Status:  new
  Component:  Core   |Version:  1.3
  (Management commands)  |   Keywords:
   Severity:  Normal |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 The current fix for #17042, although it allows more flexibility with
 regard to where `startproject` and `startapp` create the new app/project,
 doesn't actually meet the original use case that motivated that ticket.
 Several people (including at least one or two core devs) had
 [http://groups.google.com/group/django-developers/msg/4d155579ab98c536
 expressed the wish] to be able to take an existing directory that they had
 already created (for instance, initialized as a vcs repo) and convert it
 into a stock Django project using `startproject`. But the current
 implementation of the optional second argument to `startproject` doesn't
 allow you to ever reuse an existing directory, it always creates a new one
 and just allows you to specify where it will do so. To make it clearer
 with an example:

 Current behavior:
 {{{
 $ mkdir /home/carljm/target
 $ django-admin.py startproject someproj /home/carljm/target
 $ tree /home/carljm/target/
 /home/carljm/target/
 `-- someproj
 |-- manage.py
 `-- someproj
 |-- __init__.py
 |-- settings.py
 |-- urls.py
 `-- wsgi.py

 }}}

 Desired behavior:
 {{{
 $ mkdir /home/carljm/target
 $ django-admin.py startproject someproj /home/carljm/target
 /home/carljm/target/
 |-- manage.py
 `-- someproj
 |-- __init__.py
 |-- settings.py
 |-- urls.py
 `-- wsgi.py
 }}}

 Jannis (author of r17246, the fix for #17042) agreed on IRC that this
 behavior could be changed to meet the original use case.

-- 
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] #17464: [patch] Work with partial forms with the generic CreateView

[Django]

#17464: [patch] Work with partial forms with the generic CreateView
---+
 Reporter:  madjar |Owner:  madjar
 Type:  New feature|   Status:  assigned
Component:  Generic views  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by apollo13):

 * cc: florian+django@… (added)
 * stage:  Unreviewed => Accepted


Comment:

 It would be nice to have something like that, I am just not convinced if
 it's the best idea. Eg the admin does support save_form/save_model
 
(https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L698)
 -- something similar might be doable here too and would cover more than
 setting of nonform values (eg settings values based on form and request
 values 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.

Re: [Django] #15089: contrib.sites and multitenancy

[Django]

#15089: contrib.sites and multitenancy
-+-
 Reporter:  legutierr|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.sites|  Version:  1.3-beta
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-
Changes (by fernando.sanchez@…):

 * cc: fernando.sanchez@… (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #17502: Filter on field from base class 2 levels up hierarchy causes extra join

[Django]

#17502: Filter on field from base class 2 levels up hierarchy causes extra join
--+
 Reporter:  dbenamy@… |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Uncategorized |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Here's some simple code showing a 3 level concrete inheritance structure:
 {{{
 from django.db import models

 class A(models.Model):
 alice = models.IntegerField()

 class B(A):
 bob = models.IntegerField()

 class C(B):
 charlie = models.IntegerField()
 }}}

 Filtering C objects on an attribute in B or C works fine. Filtering C
 objects on an attribute in A seems to cause an extra join to A. Is there
 some reason this is needed?
 {{{
 In [3]: str(C.objects.all().query)
 Out[3]: 'SELECT "case1_a"."id", "case1_a"."alice", "case1_b"."a_ptr_id",
 "case1_b"."bob", "case1_c"."b_ptr_id", "case1_c"."charlie" FROM "case1_c"
 INNER JOIN "case1_a" ON ("case1_c"."b_ptr_id" = "case1_a"."id") INNER JOIN
 "case1_b" ON ("case1_c"."b_ptr_id" = "case1_b"."a_ptr_id")'

 In [4]: str(C.objects.filter(charlie=0).query)
 Out[4]: 'SELECT "case1_a"."id", "case1_a"."alice", "case1_b"."a_ptr_id",
 "case1_b"."bob", "case1_c"."b_ptr_id", "case1_c"."charlie" FROM "case1_c"
 INNER JOIN "case1_a" ON ("case1_c"."b_ptr_id" = "case1_a"."id") INNER JOIN
 "case1_b" ON ("case1_c"."b_ptr_id" = "case1_b"."a_ptr_id") WHERE
 "case1_c"."charlie" = 0 '

 In [5]: str(C.objects.filter(bob=0).query)
 Out[5]: 'SELECT "case1_a"."id", "case1_a"."alice", "case1_b"."a_ptr_id",
 "case1_b"."bob", "case1_c"."b_ptr_id", "case1_c"."charlie" FROM "case1_c"
 INNER JOIN "case1_b" ON ("case1_c"."b_ptr_id" = "case1_b"."a_ptr_id")
 INNER JOIN "case1_a" ON ("case1_c"."b_ptr_id" = "case1_a"."id") WHERE
 "case1_b"."bob" = 0 '

 In [6]: str(C.objects.filter(alice=0).query)
 Out[6]: 'SELECT T4."id", T4."alice", "case1_b"."a_ptr_id",
 "case1_b"."bob", "case1_c"."b_ptr_id", "case1_c"."charlie" FROM "case1_c"
 INNER JOIN "case1_b" ON ("case1_c"."b_ptr_id" = "case1_b"."a_ptr_id")
 INNER JOIN "case1_a" ON ("case1_b"."a_ptr_id" = "case1_a"."id") INNER JOIN
 "case1_a" T4 ON ("case1_c"."b_ptr_id" = T4."id") WHERE "case1_a"."alice" =
 0 '
 }}}

 This is with 1.3.1.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Changeset] r17339 - django/branches/releases/1.3.X/docs/howto/deployment

[noreply]

Author: carljm
Date: 2012-01-04 10:35:45 -0800 (Wed, 04 Jan 2012)
New Revision: 17339

Modified:
   django/branches/releases/1.3.X/docs/howto/deployment/modpython.txt
   django/branches/releases/1.3.X/docs/howto/deployment/modwsgi.txt
Log:
[1.3.X] Clarified deployment docs to avoid giving users the impression that 
staticfiles should be used to actually serve files in production.

Backport of r17338 from trunk.

Modified: django/branches/releases/1.3.X/docs/howto/deployment/modpython.txt
===
--- django/branches/releases/1.3.X/docs/howto/deployment/modpython.txt  
2012-01-04 18:08:13 UTC (rev 17338)
+++ django/branches/releases/1.3.X/docs/howto/deployment/modpython.txt  
2012-01-04 18:35:45 UTC (rev 17339)
@@ -296,8 +296,11 @@
 The admin files live in (:file:`django/contrib/admin/media/admin`) of the
 Django distribution.
 
-We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle
-the admin files, but here are two other approaches:
+We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle the
+admin files (this means using the :djadmin:`collectstatic` management command
+to collect the static files in :setting:`STATIC_ROOT`, and then configuring
+your webserver to serve :setting:`STATIC_ROOT` at :setting:`STATIC_URL`), but
+here are two other approaches:
 
 1. Create a symbolic link to the admin static files from within your
document root.

Modified: django/branches/releases/1.3.X/docs/howto/deployment/modwsgi.txt
===
--- django/branches/releases/1.3.X/docs/howto/deployment/modwsgi.txt
2012-01-04 18:08:13 UTC (rev 17338)
+++ django/branches/releases/1.3.X/docs/howto/deployment/modwsgi.txt
2012-01-04 18:35:45 UTC (rev 17339)
@@ -130,8 +130,11 @@
 The admin files live in (:file:`django/contrib/admin/media/admin`) of the
 Django distribution.
 
-We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle
-the admin files, but here are two other approaches:
+We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle the
+admin files (this means using the :djadmin:`collectstatic` management command
+to collect the static files in :setting:`STATIC_ROOT`, and then configuring
+your webserver to serve :setting:`STATIC_ROOT` at :setting:`STATIC_URL`), but
+here are two other approaches:
 
 1. Create a symbolic link to the admin static files from within your
document root.

-- 
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] r17338 - in django/trunk/docs/howto/deployment: . wsgi

[noreply]

Author: carljm
Date: 2012-01-04 10:08:13 -0800 (Wed, 04 Jan 2012)
New Revision: 17338

Modified:
   django/trunk/docs/howto/deployment/modpython.txt
   django/trunk/docs/howto/deployment/wsgi/modwsgi.txt
Log:
Clarified deployment docs to avoid giving users the impression that staticfiles 
should be used to actually serve files in production.

Modified: django/trunk/docs/howto/deployment/modpython.txt
===
--- django/trunk/docs/howto/deployment/modpython.txt2012-01-03 23:02:53 UTC 
(rev 17337)
+++ django/trunk/docs/howto/deployment/modpython.txt2012-01-04 18:08:13 UTC 
(rev 17338)
@@ -296,8 +296,11 @@
 The admin files live in (:file:`django/contrib/admin/static/admin`) of the
 Django distribution.
 
-We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle
-the admin files, but here are two other approaches:
+We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle the
+admin files (this means using the :djadmin:`collectstatic` management command
+to collect the static files in :setting:`STATIC_ROOT`, and then configuring
+your webserver to serve :setting:`STATIC_ROOT` at :setting:`STATIC_URL`), but
+here are two other approaches:
 
 1. Create a symbolic link to the admin static files from within your
document root.

Modified: django/trunk/docs/howto/deployment/wsgi/modwsgi.txt
===
--- django/trunk/docs/howto/deployment/wsgi/modwsgi.txt 2012-01-03 23:02:53 UTC 
(rev 17337)
+++ django/trunk/docs/howto/deployment/wsgi/modwsgi.txt 2012-01-04 18:08:13 UTC 
(rev 17338)
@@ -159,9 +159,12 @@
 The admin files live in (:file:`django/contrib/admin/static/admin`) of the
 Django distribution.
 
-We **strongly** recommend using :mod:`django.contrib.staticfiles` (along with
-a Web server as outlined in the previous section) to handle the admin files, 
but
-here are three other approaches:
+We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle the
+admin files (along with a Web server as outlined in the previous section; this
+means using the :djadmin:`collectstatic` management command to collect the
+static files in :setting:`STATIC_ROOT`, and then configuring your webserver to
+serve :setting:`STATIC_ROOT` at :setting:`STATIC_URL`), but here are three
+other approaches:
 
 1. Create a symbolic link to the admin static files from within your
document root (this may require ``+FollowSymLinks`` in your Apache

-- 
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] #17501: Json serialization and ugettext_lazy

[Django]

#17501: Json serialization and ugettext_lazy
-+-
 Reporter:  lars.solberg@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core |  Version:  1.3
  (Serialization)|   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jakul):

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


Comment:

 This is a duplicate of #5590 and #5868. In [ticket:5590#comment:6]
 `lukeplant (core developer)` states that it is up to clients to implement
 this code, not 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] #17501: Json serialization and ugettext_lazy

[Django]

#17501: Json serialization and ugettext_lazy
--+
 Reporter:  lars.solberg@…|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Core (Serialization)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 The json serializer will fail creating a json text when using
 ugettext_lazy objects.
 This is something DjangoJSONEncoder should handle.

 See the attached file for a git diff patch file.

 Its quite easy to fix, and I guess the fix demonstrate how the
 DjangoJSONEncoder should be coded..

-- 
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] #9025: Nested Inline Support in Admin

[Django]

#9025: Nested Inline Support in Admin
-+-
 Reporter:  pixelcort|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  1|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  1
-+-

Comment (by anonymous):

 +1 Need it a lot ;)

-- 
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] #3195: [patch] Documenting HIDDEN_SETTINGS

[Django]

#3195: [patch] Documenting HIDDEN_SETTINGS
---+
 Reporter:  cmgreen@…  |Owner:  jacob
 Type:  enhancement|   Status:  closed
Component:  Documentation  |  Version:  SVN
 Severity:  normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by anonymous):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 In addition, shouldn't this be configurable in settings.py?

-- 
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] #14976: Add is_html flag to contrib.messages

[Django]

#14976: Add is_html flag to contrib.messages
--+
 Reporter:  tedtieken |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.messages  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:  safe, messages, html  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by julien):

 * ui_ux:   => 0


Comment:

 An alternative naming could be 'allow_tags' to be consistent with
 `list_display` methods.

-- 
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] #13839: select_related caches None for non-existent objects in reverse one-to-one relations

[Django]

#13839: select_related caches None for non-existent objects in reverse 
one-to-one
relations
-+-
 Reporter:  shauncutts   |Owner:  lrekucki
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by lrekucki):

 * owner:  nobody => lrekucki
 * ui_ux:   => 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] #17500: Remove ending slashes on HTML void elements

[Django]

#17500: Remove ending slashes on HTML void elements
---+--
 Reporter:  claudep|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  SVN
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by lukeplant):

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


Comment:

 We didn't switch to HTML5 - we switched to HTML5 doctypes for bundled
 templates, especially the admin, which is quite different. We still need
 our output to be XHTML compliant as much as possible, because people could
 be using our output in XHTML templates.

 Sorry for the confusion.

-- 
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] #16250: Error with new pyscopg2 2.4.2 release and tests

[Django]

#16250: Error with new pyscopg2 2.4.2 release and tests
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by akaihola):

 A quick copy-paste script for replacing the psycopg2 Debian package with
 2.4.1 from PyPI on Ubuntu 11.10 and distributions based on it (like Linux
 Mint 12):
 {{{
 sudo apt-get remove python-psycopg2
 sudo apt-get install -y python-dev libpq-dev
 sudo apt-get install -y python-pip  # if not installed manually
 sudo pip install psycopg2==2.4.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] #17499: assertFieldOutput fails if field has customized required message

[Django]

#17499: assertFieldOutput fails if field has customized required message
---+
 Reporter:  dpifke |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by julien):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * severity:  Normal => Release blocker
 * needs_tests:   => 1
 * needs_docs:   => 0


Comment:

 Thank you for the report. Could you please provide some tests?
 Marking as release blocker since it's a new feature in 1.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] #17500: Remove ending slashes on HTML void elements

[Django]

#17500: Remove ending slashes on HTML void elements
---+
 Reporter:  claudep|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  SVN
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Django 1.4 switched to HTML5. Ending slashes on void elements are now
 optional. See also http://www.w3.org/TR/html-markup/syntax.html#syntax-
 elements.

 I suggest to remove them in HTML produced by 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.