The request & response docs for 1.3 look like:
Reference: Request/response objects | TemplateResponse objects
The first link has requests, associated request objects, and
responses. The second link has new derived response objects.
What does anyone think about reorganizing this to:
Refer
Since older "versionadded/changed" tags were dropped in 1.3, should
the admonition mentioning 0.96 on top of the admin docs also be
dropped?
"The admin site has been refactored significantly since Django
0.96."
http://docs.djangoproject.com/en/dev/ref/contrib/admin/
If so, I have a doc patch
The Django docs prefer "First word only" capitalization, though there
are some cases where seemingly random words are also capitlized,
"Views" in a couple headers here for instance:
http://docs.djangoproject.com/en/dev/topics/http/views/
Just checking that "First word only" (and also class names a
The docs seem a bit inconsistent on the use of raw lines for headings
that describe classes/methods/attributes.
The stated preference is to use a directive before the heading to make
it easier to link. Is there also a preference on whether these
headings should be raw quoted or normal text?
FWIW,
For what it's worth, there are several existing tickets on this
subject:
* http://code.djangoproject.com/ticket/5298
* http://code.djangoproject.com/ticket/8670
* http://code.djangoproject.com/ticket/12044
--
You received this message because you are subscribed to the Google Groups
"Django deve
I have a pending admin patch too: http://code.djangoproject.com/ticket/11651
(With tests and docs, though probably needs some better function
names.)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djang
ngo color,
so I can note DB related problems easier.
That probably opens up a big configuration can of worms; I haven't had
the time yet to code up a patch myself.
- Adam V.
http://adamv.com
On Nov 3, 9:33 am, Waylan Limberg wrote:
> On Tue, Nov 3, 2009 at 10:57 AM, Tobias McNulty
>
In a Django project, I have a bash script that does:
APPS=`python -c "import settings; print settings.only_our_apps()"`
./manage.py test $APPS
In settings.py I define OUR_APPS as a list, and then define
INSTALLED_APPS as the django built-ins plus OUR_APPS:
_OUR_APPS = (
'something',
'an
> To solve it I proposed[1] another strategy: delegate type conversion to the
> backend.
+1
I maintain the external django-mssql backend, and I would HUGELY
prefer to get "real Python types" instead of to-string types for
things like dates/times/decimal/etc.
(Converting everything to strings "f
> I think that it's perfectly OK to distribute a patch to change the
> hardcoded functionality -- it's far better than trying to monkey-patch
> the code under active development.
I have a patch in my backend already, to enable regex searches in MS
SQL. I think this is reasonable, as you have to i
is
that gross? Or is there a better way to handle this that I'm missing?
(Or do I just have to suck it up in my backend?)
- Adam V.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django develope
Looking in the query generation code (for both trunk and queryset-
refactor), there's special case code for RegEx clauses and Oracle, as
Oracle uses a function call syntax instead of an operator syntax.
It would be great to have this generalized for use with other engines.
SQL Server has no built
The SQL Server backend in trunk is basically broken (parameter
replacement doesn't work right), as well as missing features
(introspection being the big one.)
There have been many proposed patches, though lots of them go back to
0.91, and make lots of changes outside of the backend as well.
On m
13 matches
Mail list logo
