Vincent, it doesn't appear anyone responded to your query here. The
reason is that this list is actually for the development of django
itself. For questions that relate to the use of django, such as this,
use the django-users list instead. Take this question there or pop
into the irc channel (#
I just found a bug in some code I submitted earlier that's already
been committed. It turns out that the default options to
django-admin.py would only get read if they were the first options,
but if another option intervened, they'd get lost. In other words,
django-admin.py command --settings=pat
Malcolm --
Thanks for pointing me to that ticket -- I've composed a short patch that I
believe addresses the issue. I've attached it to the ticket for review.
http://code.djangoproject.com/attachment/ticket/5937/django-generic-relation-query.patch
-jag
On 11/16/07, Malcolm Tredinnick <[EMAIL PR
On Mon, 2007-11-19 at 19:11 +0100, Wolfram Kriesing wrote:
> [...]
> * Step 2, may be encapsulate the stuff you don't want the translators
> to touch, the same way variables get used
> {% blocktrans %}
> Received on {{ message.created|date as date }}
> from
> {{ '' as link_open }
We don't seem to be catching exceptions raised in response or request
middleware, causing bare exceptions to be displayed. Is there a reason
we are not catching these and displaying pretty error pages?
Which leads me to another observation. There seems to be a bit of
duplication in the WSGIH
On 20 nov, 17:40, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Hi Antares --
>
> Please direct questions of this nature to django-users; django-dev is
> used to discuss the development of Django itself, not to answer usage
> questions.
>
> Thanks!
>
> Jacob
Sorry!
I'll post it there.
Bye.
--
Hi Antares --
Please direct questions of this nature to django-users; django-dev is
used to discuss the development of Django itself, not to answer usage
questions.
Thanks!
Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the G
> - regarding the problem that the translation is maintained in
> chucks : if not then there is the presence of logic in the translation
> string, which is not possible I think. If you agree on that, it means
> that the translation _has_ to be maintained in chucks
This nails the main problem im
Hello, I'm programing a kind of admin zone for users, where users can
add, manage and delete objects.
I want to do it generic, but I have a big problem now.
Imagine these models:
from django.contrib.auth.models import User
class Library ( models.model ):
library_name = models.CharField(..)
Hi all,
We have created a patch which allows customizing the order of Fields in Forms.
http://code.djangoproject.com/ticket/5986
The initial idea (with weights) has been abandoned in favour of Meta
data to provide flexibility (e.g. changing order in classes inheriting
after form_for_model/form_fo
Greg_IAP wrote:
> Hello,
>
> i'm trying to understand how the method "select_related" works and it
> doesn't seems to...
>
> Does someone could explain to me how to make it work?
> several examples on the net show that it doesn't...
just a small note:
if you use select_related, make sure that
Hi,
First, I'd like to thank all people involved in this discussion for
the quality of the insightful remarks and reactions they made on my
first proposed syntax.
I'm trying to imagine improvements to my proposed syntax based on
the comments here ... unfortunately, I always find good reason
On Nov 20, 12:42 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Mon, 2007-11-19 at 10:29 -0800, Alberto Piai wrote:
> > Hello Malcolm,
>
> > SelectDateWidget from newform extras stopped working after
> > autoescaping was introduced in r6671. Here is the tiny patch to fix
> > it.
>
> Pleas
> The problem is that people pop up every couple weeks and ask precisely
> the sort of thing you're asking: in effect, "what's the status of
> this, and when will it land in trunk". The answers to these questions
> haven't changed in a very long time; what's needed is people writing
> code, not pe
14 matches
Mail list logo
