Jesse Young wrote:
> I'm guessing it's somewhat common (as usual, I think it's common
> because I do it) to put several navigational links in a template that
> is included from several other templates, e.g.:
>
> Page 1
> Page 2
> ...
> Page N
>
> But also, it's helpful to indicate where the user
I would like to propose five quite isolated improvements for
django.forms. But I think it is better to write about them in one
email - otherwise there would not be complete answers for the
problems. (More specifically, proposal 5 is very useful for proposals
1 and 2. And proposals 3 a 4 are very
I'm guessing it's somewhat common (as usual, I think it's common
because I do it) to put several navigational links in a template that
is included from several other templates, e.g.:
Page 1
Page 2
...
Page N
But also, it's helpful to indicate where the user currently is in the
navigational
Russell Keith-Magee wrote:
> On Thu, Oct 16, 2008 at 11:13 PM, Jeff Anderson
> <[EMAIL PROTECTED]> wrote:
>
>> Hello,
>>
>> #2507 has been accepted, documented, and there is a working patch. It's
>> been used in production for some time.
>>
>> In the spirit of resolving the "issue" (it is a
On Thu, Oct 16, 2008 at 11:13 PM, Jeff Anderson
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> #2507 has been accepted, documented, and there is a working patch. It's
> been used in production for some time.
>
> In the spirit of resolving the "issue" (it is a ticket after all) I see
> two choices: 1)
The max length of a varchar field is Database dependent
MySQL it is 255
MSSQL it is 2^31-1 (2gb)
PostgreSQL it is ~ 2^20-1 (1gb)
MySQL 4.1 and greater supposedly changes any varchar or char field
with a max length or greater to 255 to a TEXT field which can hold ~
1gb
Dj Gilcrease
OpenRPG
On Thu, 2008-10-16 at 15:28 -0700, adamiis111 wrote:
> I opened up a ticket regarding a bug in the django-app-plugin with
> regards to the indexed CharField being too large
> for MySQL 5.0:
>
> http://code.google.com/p/django-app-plugins/issues/detail?id=11
>
> I think that maybe Django's
The --with-handler idea for manage.py runserver sounds reasonable to
me.
I just wanted to clarify a couple of points.
> No, this isn't correct. You already have to specify which handler to
> run. You still have to do that exactly once in each case.
I meant that it requires one extra
I opened up a ticket regarding a bug in the django-app-plugin with
regards to the indexed CharField being too large
for MySQL 5.0:
http://code.google.com/p/django-app-plugins/issues/detail?id=11
I think that maybe Django's handling of this should be examined more
generally for one of the
On Thu, 2008-10-16 at 15:15 -0700, Jesse Young wrote:
> > No it's not. Since there's no common way to customize, sub-classing is
> > the perfect way to do it, since people can then do whatever they want.
> > How is asking somebody to write a subclass in Python a high barrier to
> > entry? We're
> No it's not. Since there's no common way to customize, sub-classing is
> the perfect way to do it, since people can then do whatever they want.
> How is asking somebody to write a subclass in Python a high barrier to
> entry? We're assuming knowledge of the language, but that's all.
Well, I'm
On Wed, 2008-10-15 at 18:59 -0700, Jesse Young wrote:
> Hi Malcolm,
>
> Thanks for explaining the rationale behind this. It'd certainly be
> possible to do what we want by overriding handle_uncaught_exception in
> a ModPythonHandler subclass.
>
> This method has a higher barrier to entry than
Hi,
currently it seems that the URL dispatcher makes no difference between
e.g. "/" and "%2F", which is the same if you decode it but has special
meaning in URLs. The "/" separates path segments and you would have to
encode it to "%2F" if used in such a segment. (http://en.wikipedia.org/
On Thu, Oct 16, 2008 at 3:28 PM, Wilson <[EMAIL PROTECTED]> wrote:
> Goals:
>
> 1. Make the admin CSS files easier for multiple editors and more
> version-control friendly
> 2. Reduce unnecessary complexity of the admin CSS file structure
> 3. Replace obscure CSS parser hacks currently used to
On Fri, Oct 17, 2008 at 12:54 AM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On Thu, Oct 16, 2008 at 7:11 AM, Rajeev J Sebastian
> <[EMAIL PROTECTED]> wrote:
>> Without trying to read deeply between the lines, the thread seemed to
>> come to a point where the one choice would be to document the
I've been poking around the contrib.admin CSS recently after a long
hiatus. I'm amazed at how well they've held up all this time, but
obviously after three years I've changed my mind about some of the
bright ideas I had when I wrote the first version.
Obviously, with newforms admin it's a lot
Just curious about the status of the feature request in Ticket #6362.
IMO it fits nicely with the spirit of Django in reducing repetitive
and boring work for the developer. I was originally researching this
issue with respect to URLField in particular (saw ticket #6717), since
leading or trailing
On Thu, Oct 16, 2008 at 7:11 AM, Rajeev J Sebastian
<[EMAIL PROTECTED]> wrote:
> Without trying to read deeply between the lines, the thread seemed to
> come to a point where the one choice would be to document the cases
> where in the core (i.e., django+contrib) a GET request could cause a
> db
On Oct 15, 10:18 pm, Jesse Young <[EMAIL PROTECTED]> wrote:
> Is your suggestion that, since mail_admins happens to be the only
> place in Django that uses settings.ADMINS, I could do something like:
>
> class AdminsObject(list):
> def __iter__(self):
> // do some custom notification
>
I would give the Devs a little more time as they are still deciding
what will make it into 1.1 and what wont, as well as fixing bugs in
the 1.0.x branch.
I use this for two of my projects and would love to see it included in
release, but it is not that hard to add on my own
Dj Gilcrease
OpenRPG
Jesse Young wrote:
> The built-in behavior for
> django.core.handlers.base.handle_uncaught_exception calls mail_admins
> for each internal server error.
>
> So if a very high-traffic view has an internal server error, duplicate
> emails will be sent at a very high rate. This isn't usually
>
Hello,
#2507 has been accepted, documented, and there is a working patch. It's
been used in production for some time.
In the spirit of resolving the "issue" (it is a ticket after all) I see
two choices: 1) Merge it into Django. 2) close it as wontfix and host
the code somewhere else.
It was
Hi Ned,
On Thu, Oct 16, 2008 at 5:22 PM, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> At one point, Amit used the phrase "should Django enforce it?", which sounds
> like more than documentation to me. Changing Django so that GETs couldn't
> modify the database would be a bad idea. There are
23 matches
Mail list logo
