On Sat, Jun 18, 2011 at 12:26 PM, Ori wrote:
> Hi guys,
>
> Apologies if this isn't the right venue for raising the alarm, but it
> seems djangoprojects.com is down.
Hi Ori,
Thanks for the alert -- I'm trying to find someone with the keys to
give the server a kick in a sensitive spot.
Yours,
Ru
Hi guys,
Apologies if this isn't the right venue for raising the alarm, but it
seems djangoprojects.com is down.
Cheers,
Ori
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegrou
Thanks, Carl. :-)
I probably should've written a thank you note sooner & separately. As
it is, I am also writing to request a five-for-one again.
I have reviewed:
16168
16173
16176
16235
16237
I would love it if someone could look at 13956 [1]
Best,
Stephen
[1] http://code.djangoproject.com/tic
On Fri, Jun 17, 2011 at 4:15 PM, Bas Peschier wrote:
> Hello everyone,
>
> after discussion on IRC with rasca I opened up a ticket [1] about
> making FormSets declarable.
>
> We have been down this route with ModelForm and it seems to make sense
> to be able to declare your FormSet somewhere inste
On Fri, Jun 17, 2011 at 6:45 PM, Vinay Sajip wrote:
> Matt Bennett writes:
>
>>
>> > This is a case for a custom Filter object [1]. The filter object
>> > implementation would only be a few lines, to reject logging when DEBUG
>> > is True, and can be attached to the admin email handler in the def
Hello everyone,
after discussion on IRC with rasca I opened up a ticket [1] about
making FormSets declarable.
We have been down this route with ModelForm and it seems to make sense
to be able to declare your FormSet somewhere instead of having to
generate it.
The idea given is you can do:
cla
Hello everyone,
A couple months ago I started work on a django branch [1] (with the help of
@jezdez) that introduces a framework for writing javascript unit tests using
QUnit[2]. I started with QUnit because Django already included jQuery in
the admin and seemed like a natural extension, but it w
On Jun 17, 8:02 pm, Ian Kelly wrote:
> The thing is, this is a DB API snippet, not a Django snippet
> specifically. If Django were a DB API toolbox, then it might make
> sense to include it in some form or other. But it's not, so in the
> interest of keeping things relatively tidy I'm a -0 on t
Matt Bennett writes:
>
> > This is a case for a custom Filter object [1]. The filter object
> > implementation would only be a few lines, to reject logging when DEBUG
> > is True, and can be attached to the admin email handler in the default
> > logging configuration. [2] This way the logging ca
Hi Julien,
On 06/17/2011 12:08 PM, Julien Phalip wrote:
> Just noting that another "filtering" functionality has recently been
> added to trunk [1]. It is a different kind of filtering than what's
> being discussed here -- it is to filter out sensitive information from
> error reports when they're
On Jun 17, 10:48 pm, Matt Bennett wrote:
> > This is a case for a custom Filter object [1]. The filter object
> > implementation would only be a few lines, to reject logging when DEBUG
> > is True, and can be attached to the admin email handler in the default
> > logging configuration. [2] This wa
On Fri, Jun 17, 2011 at 5:54 AM, Cal Leeming [Simplicity Media Ltd]
wrote:
> Because I feel this is just something that should work (or be available) out
> of the box. There are plenty of other places where Django docs has included
> code snippets to give the user a heads up, and I think this is t
On Jun 17, 2:54 pm, "Cal Leeming [Simplicity Media Ltd]"
wrote:
> Because I feel this is just something that should work (or be available) out
> of the box. There are plenty of other places where Django docs has included
> code snippets to give the user a heads up, and I think this is the perfect
Hi Matt,
On 06/17/2011 07:48 AM, Matt Bennett wrote:
> Since logging Filters are not specific to an individual logger or
> handler, I've just called it DebugFalseFilter. It's not a pretty name,
> but I couldn't come up with anything better - I decided it should
> convey what the filter allows thro
On Fri, Jun 17, 2011 at 5:18 AM, Anatoly Vostryakov
wrote:
> Hi, Armin!
>
> I've thought today. May be it will possible to add support of
> parameters for functions or object methods in django templates.
> I mean, something like this in django template:
>
> {{ obj.method(parameter1, parameter2)
Hi, Armin!
I've thought today. May be it will possible to add support of
parameters for functions or object methods in django templates.
I mean, something like this in django template:
{{ obj.method(parameter1, parameter2) }}
How I remember it is possible in jinja2 someway and it is what I
> This is a case for a custom Filter object [1]. The filter object
> implementation would only be a few lines, to reject logging when DEBUG
> is True, and can be attached to the admin email handler in the default
> logging configuration. [2] This way the logging call can occur in all
> code paths,
Because I feel this is just something that should work (or be available) out
of the box. There are plenty of other places where Django docs has included
code snippets to give the user a heads up, and I think this is the perfect
case for one.
If anyone has any objections to this, please let me know
On 17/06/11 07:00, Tai Lee wrote:
> If this behaviour were to change, `required` would become a completely
> meaningless argument to BooleanField because no value in the GET or
> POST data is normalised to `False` because of the way checkbox values
> are submitted in HTML forms.
The suggestion is
19 matches
Mail list logo
