Hello all :)
I launched the ticket #6275 but I think my poor english was not the
things clear.
brosner said the idea "out of scope" and ubernostrum said "Django
does not and will not attempt to dictate where you put your code".
but wish to try to explain to be more clear (I think these guys
un
On 28 Dec 2007, at 7:06 am, Collin Grady wrote:
>
> I've never bothered bringing this up before as it's never really been
> needed, but tonight we had someone with a rogue script in their IRC
> client which prevented them from closing their client, and flooded the
> channel with "hello world" fo
On Dec 28, 2007 5:19 AM, Marinho Brandao <[EMAIL PROTECTED]> wrote:
> when I said "a place to put in applications", I did not saying a hard
> place to put the applications, but a more flexible way to import them
> from. The solution could be a registration (i.e like template tags) by
> an kind of
On Dec 28, 2007 2:38 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> On Dec 28, 2007 11:35 AM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> >
> > I'm happy to take care of this -- I just don't know what's involved in
> > registering a channel. Could you provide some more information on whom
> > to
On Dec 28, 2007 11:35 AM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> I'm happy to take care of this -- I just don't know what's involved in
> registering a channel. Could you provide some more information on whom
> to talk to about getting it done?
>
http://freenode.net/group_registration.sht
On Dec 28, 2007 1:06 AM, Collin Grady <[EMAIL PROTECTED]> wrote:
> I've never bothered bringing this up before as it's never really been
> needed, but tonight we had someone with a rogue script in their IRC
> client which prevented them from closing their client, and flooded the
> channel with "he
I have a use case where a Form superclass includes fields at the top
and bottom of the form, with the subclasses providing the fields in
the middle. Obviously, there's no easy way to fix the ordering using
simple declaration. I went on IRC and someone told me about overriding
self.fields.keyOrder
On Dec 28, 2007 3:04 PM, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
> I have a use case where a Form superclass includes fields at the top
> and bottom of the form, with the subclasses providing the fields in
> the middle. Obviously, there's no easy way to fix the ordering using
> simple declaratio
That's a very good idea, though I still think a short version (which
is all I've written) belongs in the docs. Here's the relevant part:
Index: django/docs/newforms.txt
===
--- django/docs/newforms.txt(revision 6979)
+++ django/d
Haven't really thought about this too much, just wanted to throw the
idea out (mainly for Malcolm)
Currently, widgets are conditionally escaped [1]. Malcolm points out
that "This still isn't perfect behaviour (since it's unaware of the
current context's auto-escaping setting)..."
If the template
10 matches
Mail list logo