Re: rethinking raw_id_fields

Hi Subsume, why not just replace them with some proper implementation of ajax completion ? http://djangopackages.com/grids/g/auto-complete/ On Thu, Sep 30, 2010 at 12:34 PM, subs...@gmail.com wrote: > Hello all, > > I was browsing the tickets and saw a few of them nagging about some > restricti

Re: ANN: Improving our decision-making and committer process

On 09/30/2010 03:46 AM, Russell Keith-Magee wrote: Accepted tickets can be: * Purely accepted, indicating that someone has verified that the problem exists, but not how to solve it * Accepted with a patch that is wrong in some way (e.g., fixing the symptom, not the problem) * Accepted wi

Re: ANN: Improving our decision-making and committer process

On Thursday, September 30, 2010, Ivan Sagalaev wrote: > On 09/30/2010 03:46 AM, Russell Keith-Magee wrote: > > Accepted tickets can be: > >  * Purely accepted, indicating that someone has verified that the > problem exists, but not how to solve it > >  * Accepted with a patch that is wrong in so

Re: Error email flooding on high traffic production sites

Hi, Sorry the digging up an old thread, I'm a bit behind on my reading of django-dev. I have a patch in the bug tracker that fixes this exact problem - http://code.djangoproject.com/ticket/11565. The patch is just over a year old now so it might not apply that cleanly to the current trunk. The p

Re: No caching if request.GET not empty

I updated the patch http://code.djangoproject.com/attachment/ticket/4992/cache_by_request_full_path_v2.diff I think it is ready for commit. The patch has docs and tests. Can someone please test it on different plattforms? I used: Python 2.5.1 on linux. Thomas Mikhail Korobov wrote: > Hi T

Need opinion for an object permission rule backend

Hi everyone, I have been recently thinking about an object permission system. After reviewing Florian Apolloner (apollo13) patch for ticket #11010 and reading his article at Django Advent. I though about c

Re: Need opinion for an object permission rule backend

On Thu, 2010-09-30 at 13:29 +0200, Miguel Araujo wrote: > Hi everyone, > > > I have been recently thinking about an object permission system. After > reviewing Florian Apolloner (apollo13) patch for ticket #11010 and > reading his article at Django Advent. I though about creating an > Object Perm

Re: Need opinion for an object permission rule backend

> > Since you are not suggesting something for inclusion in Django itself, > this is not the right mailing list for this kind of post. You don't need > the opinion of the core Django developers for this - the publicly > documented APIs and normal Python/programming practices give you > everything y

#12012 Logging: Final call for comments

Hi all, A final call for comment before I commit #12012 to trunk. Barring objection, my intention is to commit this early next week. I've integrated the suggestions that have arisen since the first draft: * This patch has docs :-) There aren't any tests though, and I think it's going to have to

Re: #12012 Logging: Final call for comments

On Thu, Sep 30, 2010 at 8:56 AM, Russell Keith-Magee wrote: > If you have any objections, now is the time to raise them. This isn't an objection, per se -- don't let it stop you committing -- but I'm somewhat concerned with the verbosity of the LOGGING setting. We're adding 40 lines of configurat

Re: #12012 Logging: Final call for comments

On Thu, Sep 30, 2010 at 10:03 PM, Jacob Kaplan-Moss wrote: > On Thu, Sep 30, 2010 at 8:56 AM, Russell Keith-Magee > wrote: >> If you have any objections, now is the time to raise them. > > This isn't an objection, per se -- don't let it stop you committing -- > but I'm somewhat concerned with the

Re: Need opinion for an object permission rule backend

Take a look in the django-guardian project http://github.com/lukaszb/django-guardian Regards, Cesar 2010/9/30 Miguel Araujo > Since you are not suggesting something for inclusion in Django itself, >> this is not the right mailing list for this kind of post. You don't need >> the opinion of the

Re: ANN: Improving our decision-making and committer process

On 09/30/2010 01:22 PM, Russell Keith-Magee wrote: So, let me be clear on what you're proposing: you acknowledge that the triage process is backlogged. Your proposal is to put extra workload onto the core team - the one group that is already a bottleneck in the process. Pretty much. I just don'

Re: rethinking raw_id_fields

At that point its not really raw_id_fields, is it? =) -Steve On Sep 30, 3:07 am, "burc...@gmail.com" wrote: > Hi Subsume, > > why not just replace them with some proper implementation of ajax completion ? > > http://djangopackages.com/grids/g/auto-complete/ > > On Thu, Sep 30, 2010 at 12:34 PM,

Proposal: Combine aggregation docs

Django's aggregation is a great tool. That said; if I'm a new user who knows it exists but not how it works, I'll likely pull up the page about Aggregation (http://docs.djangoproject.com/en/dev/topics/db/ aggregation/). This page gives an excellent overview, but leaves me feeling like there is some

Re: #12012 Logging: Final call for comments

Russ, This will be a welcomed addition to debugging Django apps. I have a question about startup.py. I notice that startup runs after settings are loaded, but before models. Does this mean that code within startup.py cannot safely access the ORM? If the ORM is fully accessible in startup.py, it's

Re: rethinking raw_id_fields

On Thu, Sep 30, 2010 at 10:27 PM, subs...@gmail.com wrote: > At that point its not really raw_id_fields, is it? =) After all, what's the purpose of these fields? -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- You received this message because you

Re: Need opinion for an object permission rule backend

Thanks Cesar Canassa. I didn't know this project, I have had a look at the code. The only problem I see with this backend, as the one explained by Apolloner, is the fact, that I don't think it can scale very well. There are so many combinations of object.ids and user.ids to handle, that my approac

Re: Proposal: Combine aggregation docs

On Thu, Sep 30, 2010 at 11:34 AM, Yo-Yo Ma wrote: > I would > propose putting an aggregation function list on that page, rather than > letting the user eventually find the list at the bottom of the > QuerySet page. Or, put a prominent link near the top that suggests > visiting QuerySet docs for a

Re: rethinking raw_id_fields

Yeah, I think your right. raw_id_fields is a neat idea if you really are reluctant to use AJAX. If introducing AJAX into admin is fine, dumping these fields altogether seems the best approach. As for the options given, I've only used ajax-selects. I think its implementation is rather cumbersome in

Re: be localflavor Belgium

I updated the be localflavor patch to use unit tests instead of doctests as requested. Can you check if this is what you want. There was no unit tests in regressiontests/forms/localflavor/ so I am not 100% sure I did what is expected. I took a look at the ones in regressiontests/forms as models. O

Re: be localflavor Belgium

On Fri, Oct 1, 2010 at 6:15 AM, Laurent Luce wrote: > I updated the be localflavor patch to use unit tests instead of > doctests as requested. Can you check if this is what you want. There > was no unit tests in regressiontests/forms/localflavor/ so I am not > 100% sure I did what is expected. I t

Re: #12012 Logging: Final call for comments

On Fri, Oct 1, 2010 at 1:53 AM, Andy McCurdy wrote: > Russ, > This will be a welcomed addition to debugging Django apps. I have a question > about startup.py. I notice that startup runs after settings are loaded, but > before models. Does this mean that code within startup.py cannot safely > acces

Re: rethinking raw_id_fields

And then it was so: http://code.djangoproject.com/ticket/14370 On Sep 30, 3:54 pm, "subs...@gmail.com" wrote: > Yeah, I think your right. raw_id_fields is a neat idea if you really > are reluctant to use AJAX. If introducing AJAX into admin is fine, > dumping these fields altogether seems the be

Re: #12012 Logging: Final call for comments

re: verbose logging configuration. This bothered me as well initially, though after starting to use logging extensively I realized that there isn't really a more concise way to provide all of the features that the logging config brings to the table. We can however, create a very concise default s

Re: rethinking raw_id_fields

I've tried implementing Autocomplete for the admin using jQuery (new) Autocomplete, here's the code: http://bitbucket.org/tyrion/django and here's a live demo (without css for the autocomplete, so it looks kinda ugly): http://djangoac.tyrion.mx/admin/ login with test/test. Let me know what you thi

#6735 -- Class based generic views: call for comment

Hi all, I've just added a summary of the last thread on class-based views [1]. This summary isn't 100% complete -- any contributions from interested parties are welcome. Try to keep opinions to a minimum; this page is about documenting the strengths and weaknesses of various approaches, not about

Re: #6735 -- Class based generic views: call for comment

> > I already have one specific piece of API feedback: the current > implementation requires that all view logic is contained in GET(), > POST() etc style views. This is fine, except for the fact that there > are occasions where GET and POST share a lot of common logic. It would > make sense to me

Re: #12012 Logging: Final call for comments

Hi all, Following feedback from Jacob and others in IRC, I've just uploaded an RC2 patch. This patch: * Dramatically simplifies the logging configuration, removing everything that isn't absolutely required. * Adds a note in the project template settings.py telling the user what the default co

Re: ANN: Improving our decision-making and committer process

On Sep 30, 7:22 pm, Russell Keith-Magee wrote: > What is also needed is a whole lot more people volunteering. Any > suggestions on how to get more people doing the entirely unglamorous, > but completely necessary work will be gratefully accepted. I'd like to suggest (1) easy to find and use pre-

Sites Framework: RequestSite and get_current

I went to triage a few tickets tonight, and noticed that #8960, #10235, #10608 and #13814 have all arrived at essentially the same conclusion: there needs to be a single idiomatic way to get either the current Site object if contrib.sites is installed, or a RequestSite object if not. All four ticke