Michael Glassford kirjoitti:
>
>
> Alex Gaynor wrote:
>
>> Can you upload it with a .diff extension so we can get proper code
>> highlighting on trac.
>>
>> Alex
>>
>
> Sorry. Done.
I did a quick look and what I understand now it only supports client
side on_delete actions (cascade, protect
On Tue, Oct 13, 2009 at 9:48 AM, Jacob Kaplan-Moss wrote:
> The best solution, I think, would be to implement user messages
> (user.message_set, get_and_delete_messages, etc) in terms of the new
> framework, and then gradually deprecate and remove the old APIs.
On Tue, Oct 13, 2009 at 10:30 PM,
On Tue, Oct 13, 2009 at 8:13 PM, Russell Keith-Magee
wrote:
> I was hoping for a little more detail than this - this is just
> Django's general deprecation plan, and I wouldn't expect that to
> change. What exactly do these steps mean in practice? What changes are
> going to be made to (for examp
Just a couple random thoughts/clarifications after reading the Django
1.2 feature votes:
* The proposed messaging app will definitely leverage the cookie
signing utilities also in store for 1.2.
* This is a compelling core feature for me, at least, because a
standard needs to be set that reusa
On Tue, Oct 13, 2009 at 9:54 AM, Paul McLanahan wrote:
> This may be adding undue complexity, but I wanted to throw it out and
> see what you thought anyway. I think a possible solution to Russ' last
> two points may indeed be overloading the "messages" template variable.
> What I'm thinking is t
On Tue, Oct 13, 2009 at 9:48 AM, Jacob Kaplan-Moss wrote:
> This is my main concern, and the thing keeping me from being
> enthusiastic about the current state of the proposal. Many apps --
> including, notably, django.contrib.admin -- rely on user.message_set.
> We can't simply remove it; we nee
Hello all,
I'm the author of Contrib-09/#11526[1], an LDAP authentication
backend. I haven't posted about it before and I saw some questions in
the voting sheet, so I thought I'd try to address them here.
My motivation for writing the backend is simply that I'm managing a
server with a var
On Wed, Oct 14, 2009 at 7:45 AM, Tobias McNulty wrote:
>
> On Tue, Oct 13, 2009 at 3:27 AM, Russell Keith-Magee
> wrote:
>> Secondly, I share Chris' concern about overloading 'messages'. This
>> overlaps with the bikeshed issue of what to call the new contrib
>> package - whatever name is picked
On Tue, Oct 13, 2009 at 3:27 AM, Russell Keith-Magee
wrote:
> as an alias. Note that this is a reversal of argument order from the
> proposed API. I'm not absolutely tied to this suggestion - I'm just
> noting that adding Django support for Python logging is also on the
> cards for v1.2, and it s
Jacob,
yeah, found django-filters mentioned few times at Admin-02 notes.
Ok, nice, idea isn't abandoned.
On Wed, Oct 14, 2009 at 2:38 AM, Yuri Baburov wrote:
> Hi Jacob,
>
> Could you please add "Add Alex's django-filters
> (http://github.com/alex/django-filter) instead of admin filters and
> #
Hi Jacob,
Could you please add "Add Alex's django-filters
(http://github.com/alex/django-filter) instead of admin filters and
#5833 Custom FilterSpecs proposal" feature idea into your google
spreadsheets doc and vote for it.
I was "late to the party" when you told you're going to vote on
features
Alex Gaynor wrote:
> Can you upload it with a .diff extension so we can get proper code
> highlighting on trac.
>
> Alex
>
Sorry. Done.
Mike
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers"
On Tue, Oct 13, 2009 at 4:36 PM, Michael Glassford wrote:
>
>
>
> Jani Tiainen wrote:
>> Michael Glassford kirjoitti:
>>>
>>> Jani Tiainen wrote:
Is there anyone working for this ticket?
There seemed to be few patches but then a silence.
I would be interested in to help/i
Jani Tiainen wrote:
> Michael Glassford kirjoitti:
>>
>> Jani Tiainen wrote:
>>> Is there anyone working for this ticket?
>>>
>>> There seemed to be few patches but then a silence.
>>>
>>> I would be interested in to help/implement that feature since it's very
>>> highly needed feature in our o
On Oct 13, 3:12 pm, Benjamin Slavin wrote:
> It looks like I may actually be able to put a bit of time toward a new
> implementation for this, so I'll keep the list posted.
As I said, great! But I thought I would have a go, too. Here's what I
did: changed Django in two places, conf/__init__.py
On Tue, Oct 13, 2009 at 12:38 PM, Jacob Kaplan-Moss wrote:
>
> Hey folks --
>
> Like last time 'round, if you'd like to express an opinion about
> features for Django 1.2, go and vote:
>
>
> http://spreadsheets.google.com/ccc?key=0AtIlKMKDxMBpdGVPVXlTODVLeTBpNkdLd3hqZzdYR3c&hl=en
>
> I've reorgani
On Oct 13, 3:12 pm, Benjamin Slavin wrote:
> On Tue, Oct 13, 2009 at 2:17 AM, Vinay Sajip wrote:
> > I know it was sloppy of me to call it "INSTALLED_APPS loading" as that
> > happens in db/models/loading.py - I thought it would be clear from my
> > saying I was talking about calling from Settin
On Tue, Oct 13, 2009 at 2:17 AM, Vinay Sajip wrote:
> I know it was sloppy of me to call it "INSTALLED_APPS loading" as that
> happens in db/models/loading.py - I thought it would be clear from my
> saying I was talking about calling from Settings.__init__().
Ok... I see what you're saying. I'v
On Tue, Oct 13, 2009 at 3:27 AM, Russell Keith-Magee
wrote:
> Secondly, I share Chris' concern about overloading 'messages'. This
> overlaps with the bikeshed issue of what to call the new contrib
> package - whatever name is picked for the contrib package should
> probably be reflected in the co
On Tue, Oct 13, 2009 at 14:22, Tobias McNulty wrote:
> On Tue, Oct 13, 2009 at 3:53 AM, Hanne Moa wrote:
>> In fact, it would be very useful to both log and add a message at the
>> same time, iff there is an error. So that shouldn't deliberately be
>> made hard to do but maybe suitable for a laz
On Tue, Oct 13, 2009 at 2:27 AM, Russell Keith-Magee
wrote:
> Lastly, one issue that seems unaddressed is the transition plan for
> replacing user.message_set. The preamble to the wiki page makes a
> compelling argument for ditching message_set, but remains silent on a
> proposal for how Django (
You may think this is extremely silly, but I like the small tutorial, but
would like it better if it were expanded somewhat, with more troubleshooting
paragraphs in it. It already has a few of these, but it would cut down on
my struggles if it had a few more. Maybe a complete (this really works,
Hey folks --
Like last time 'round, if you'd like to express an opinion about
features for Django 1.2, go and vote:
http://spreadsheets.google.com/ccc?key=0AtIlKMKDxMBpdGVPVXlTODVLeTBpNkdLd3hqZzdYR3c&hl=en
I've reorganized the 1.2 feature list
(http://code.djangoproject.com/wiki/Version1.2Featu
On Tue, Oct 13, 2009 at 3:53 AM, Hanne Moa wrote:
> In fact, it would be very useful to both log and add a message at the
> same time, iff there is an error. So that shouldn't deliberately be
> made hard to do but maybe suitable for a lazy man's shortcut: one call
> that does both.
That is bindi
I don't agree with one calling doing logging and notices. There's really no
reason to mix in logging with the notices framework as they serve completely
different purposes. I believe Russel is just suggesting the APIs match so
that there is no additional learning curve, which makes complete sense.
On Sun, Oct 11, 2009 at 11:15 PM, Russell Keith-Magee <
freakboy3...@gmail.com> wrote:
>
> On Mon, Oct 12, 2009 at 7:15 AM, Zachary Voase
> wrote:
> >
> > On 11 Oct 2009, at 23:39, Joshua Russo wrote:
> >
> >> How about the possibility of an advanced tutorial, to highlight more
> >> advanced feat
Hi!
If a core developer would take a look at
http://code.djangoproject.com/ticket/6552
and indicate whether the approach is the right one, that would be
great.
Short version of the story: using django.core.context_processors.auth
is the same as saying "all pages depend on who is currently logg
On Tue, Oct 13, 2009 at 3:34 AM, Tobias McNulty wrote:
>
> Before we get too far, I'd appreciate hearing feedback from one or
> more of the core devs (and from some of the folks who were involved in
> this discussion back when it was happening on the ticket) on the wiki
> page[1] and the general
On Tue, Oct 13, 2009 at 09:27, Russell Keith-Magee
wrote:
> I'm just
> noting that adding Django support for Python logging is also on the
> cards for v1.2, and it seems weird that we would introduce two APIs
> with similar external APIs, but not try to maintain parity.
In fact, it would be very
29 matches
Mail list logo
