About applications "registration" or something like this

2007-12-28 Thread Marinho Brandao
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

Re: #django registration

2007-12-28 Thread David Reynolds
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

Re: About applications "registration" or something like this

2007-12-28 Thread Marty Alchin
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

Re: #django registration

2007-12-28 Thread Ramiro Morales
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

Re: #django registration

2007-12-28 Thread Jeremy Dunck
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

Re: #django registration

2007-12-28 Thread Adrian Holovaty
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

newforms Form.fields.keyOrder

2007-12-28 Thread Todd O'Bryan
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

Re: newforms Form.fields.keyOrder

2007-12-28 Thread Marty Alchin
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

Re: newforms Form.fields.keyOrder

2007-12-28 Thread Todd O'Bryan
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

needs_autoescape property on methods

2007-12-28 Thread SmileyChris
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