Re: Gentle Proposal: add 'render' shortcut in 1.3

2010-10-27 Thread Ivan Sagalaev
On 10/27/2010 04:55 PM, Mikhail Korobov wrote: 1. 'Border' middleware is a backwards-compatible change, the requirement to bake response in middleware isn't. The difference is only that you propose to execute 'bake' in the end of response cycle and I propose to execute it at the beginning of the

Re: contrib.staticfiles app concerns

2010-10-27 Thread Waldemar Kornewald
Hi Yuri, On Thu, Oct 28, 2010 at 6:19 AM, burc...@gmail.com wrote: > Hi Waldemar, > > On Wed, Oct 27, 2010 at 9:05 PM, Waldemar Kornewald > wrote: >> 2010/10/27 Mikhail Korobov : >>> Why isn't it fine to have different URL rewriting schemes for >>> different assets bundlers? >> >> OK, sorry for

Re: contrib.staticfiles app concerns

2010-10-27 Thread burc...@gmail.com
Hi Waldemar, On Wed, Oct 27, 2010 at 9:05 PM, Waldemar Kornewald wrote: > 2010/10/27 Mikhail Korobov : >> Why isn't it fine to have different URL rewriting schemes for >> different assets bundlers? > > OK, sorry for not having explained it well. What I mean is this: > Imagine this code snippet in

Re: More efficient negative lookups

2010-10-27 Thread George Vilches
On Oct 27, 5:55 pm, Jacob Kaplan-Moss wrote: > On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty wrote: > > I'm inclined to say we do the former -- restore the "ne" lookup type > > -- because it's a quick fix, and ask somebody to write up a patch for > > the latter. Does anybody have strong opin

Re: More efficient negative lookups

2010-10-27 Thread Adrian Holovaty
On Wed, Oct 27, 2010 at 4:55 PM, Jacob Kaplan-Moss wrote: > However, just for the record I think the reason we decided to remove > __ne is the first place was that its existence introduces a weird > inconsistency with regard to other lookup types. That is, if there's a > "ne" why isn't there a "ns

Re: More efficient negative lookups

2010-10-27 Thread Alex Gaynor
On Wed, Oct 27, 2010 at 5:55 PM, Jacob Kaplan-Moss wrote: > On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty wrote: >> I'm inclined to say we do the former -- restore the "ne" lookup type >> -- because it's a quick fix, and ask somebody to write up a patch for >> the latter. Does anybody have str

Re: More efficient negative lookups

2010-10-27 Thread Jacob Kaplan-Moss
On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty wrote: > I'm inclined to say we do the former -- restore the "ne" lookup type > -- because it's a quick fix, and ask somebody to write up a patch for > the latter. Does anybody have strong opinions against this? If not, I > can restore the "ne" look

More efficient negative lookups

2010-10-27 Thread Adrian Holovaty
Hi all, I'd like to fix an inefficiency in our ORM's negative lookups. A long, long time ago, we had an "ne" lookup for QuerySet.filter(), which would let us do "not equals" lookups, like this: MyModel.objects.filter(slug__ne='ignoreme') Unfortunately, we removed this lookup type in http://code

Re: Bump/question for #13956

2010-10-27 Thread Stephen Burrows
Thanks for the suggestion. I've added tests for the inclusion tags, so now everything is being tested that I could think of - with the exception of inclusion tags that have takes_context=True. Really, though, they should act the same way from the tag's point of view. The only difference is that if

Re: Django on Google App Engine via SQL (not nonrel)

2010-10-27 Thread Antonio Ognio
Hi Wesley, Maybe it would also be helpful to point out in advance what known behaviors (often considered as limitations) of the datastore will be carried to the MySQL compatibility layer that Django would have to deal with. For example, currently using GQL counting the number of rows returned by

Re: Gentle Proposal: add 'render' shortcut in 1.3

2010-10-27 Thread Mikhail Korobov
Hmm, and now I don's see a use case for the 'force_bake' (and maybe even public 'bake' method) method if BakingMiddleware is implemented. With BakingMiddleware there is exactly one place where response should be baked and user's code shouldn't be calling 'force_bake' and even 'bake' on responses.

Re: contrib.staticfiles app concerns

2010-10-27 Thread Waldemar Kornewald
2010/10/27 Mikhail Korobov : > Why isn't it fine to have different URL rewriting schemes for > different assets bundlers? OK, sorry for not having explained it well. What I mean is this: Imagine this code snippet in a reusable app's CSS file: /* myapp/style.css */ div.icon { background-image: u

Re: Gentle Proposal: add 'render' shortcut in 1.3

2010-10-27 Thread Mikhail Korobov
Hi Ivan, Let me explain why I prefer 'border' middleware way (that is implemented) over explicit baking in messages middleware (that was implemented but then replaced with 'border' middleware). 1. 'Border' middleware is a backwards-compatible change, the requirement to bake response in middleware

Re: contrib.staticfiles app concerns

2010-10-27 Thread Mikhail Korobov
Why isn't it fine to have different URL rewriting schemes for different assets bundlers? E.g. if one uses django-compress he should list all files he wants to combine in settings.py and then output them into template as {% compressed_css 'my_css' %}. If one is using django-compressor then he list

Re: Permission support for admin inlines

2010-10-27 Thread Florian Apolloner
Hi, the permission checking should be doable if my ideas from http://groups.google.com/group/django-developers/browse_thread/thread/bfad2774ff7c357b# get in. So if someone can come up with a proper api as suggested by Russell I'd be happy to help codewise (this way we could even work around the DD

Re: It is real to add ticket #8054 to 1.3 milestone?

2010-10-27 Thread burc...@gmail.com
Hi Mikhail, On Wed, Oct 27, 2010 at 5:45 PM, Mikhail Korobov wrote: > Hi Alex and Yuri, > > To make it clear: is this only a syntax change and all other benefits > can be achieved with current implementation? > > The benefits from the wiki: > > 1. ability to customize and localize 3rd-party appli

Re: It is real to add ticket #8054 to 1.3 milestone?

2010-10-27 Thread Russell Keith-Magee
On Wed, Oct 13, 2010 at 12:47 AM, alekam wrote: > Hi All, > > I found very useful ticket #8054. This ticket has accepted status and > assigned to brosher about 2 years. The problem describes on ticket > detail page and in the wiki http://code.djangoproject.com/wiki/ListColumns > The ticket has pat

Re: contrib.staticfiles app concerns

2010-10-27 Thread Waldemar Kornewald
Hi Mikhail, On Wed, Oct 27, 2010 at 1:14 PM, Mikhail Korobov wrote: > Hi Waldemar, > > Could you explain why is this should belong to django staticfiles app? > This app has nothing to do with combining css files. It has one view > (django.contrib.staticfiles.views.serve) in order to serve files i

Re: prepopulated_fields javascript error since r14123

2010-10-27 Thread Simon Meers
On 27 October 2010 19:40, Andrew Godwin wrote: > On 27/10/10 07:01, Simon Meers wrote: > >> Has anyone else found that using prepopulated_fields in admin.ModelAdmin >> since r14123 produces a javascript error: "d.join is not a function"? >> > > I didn't get any errors when I tested the patch befo

Re: contrib.staticfiles app concerns

2010-10-27 Thread Mikhail Korobov
Hi Waldemar, Could you explain why is this should belong to django staticfiles app? This app has nothing to do with combining css files. It has one view (django.contrib.staticfiles.views.serve) in order to serve files in development. This is only a helper view used in development and I don't see w

Re: It is real to add ticket #8054 to 1.3 milestone?

2010-10-27 Thread Mikhail Korobov
Hi Alex and Yuri, To make it clear: is this only a syntax change and all other benefits can be achieved with current implementation? The benefits from the wiki: 1. ability to customize and localize 3rd-party application without fork it - it is as easy with current ModelAdmin. ModelAdmin looks up

Re: contrib.staticfiles app concerns

2010-10-27 Thread Waldemar Kornewald
On Thu, Oct 21, 2010 at 10:10 PM, Waldemar Kornewald wrote: > OK, I just went through django-mediagenerator to check if there's > anything else needed by staticfiles and I noticed that we need to have > a standard for URLs in CSS files (e.g., url(image.png)). > > Since we don't know the STATICFILE

Re: prepopulated_fields javascript error since r14123

2010-10-27 Thread Andrew Godwin
On 27/10/10 07:01, Simon Meers wrote: Has anyone else found that using prepopulated_fields in admin.ModelAdmin since r14123 produces a javascript error: "d.join is not a function"? I didn't get any errors when I tested the patch before commit - are you having them on the 1.2.X backport, or th

Re: Ticket #7817: Extending "with" and "include" tags.

2010-10-27 Thread David Danier
> Other tags which currently use the "as" token are: cycle, regroup and > url. These all introduce a new variable into the current context, > which does differ slightly from how {% with %} alters a variable in a > contained scope. So my secondary (perhaps somewhat feeble) argument is > that this ac

Re: Ticket #7817: Extending "with" and "include" tags.

2010-10-27 Thread SmileyChris
On Oct 27, 5:35 am, Łukasz Rekucki wrote: > I would like to bring this up again, because this is something that > would really improve readability of my templates. I'm mainly > interested in ticket #7817 (the include tag changes), but extending > "with" tag (ticket 9456) would keep things consiste

Re: Gentle Proposal: add 'render' shortcut in 1.3

2010-10-27 Thread Ivan Sagalaev
On 10/25/2010 04:33 PM, Russell Keith-Magee wrote: * The problem with messages is a big one -- probably even a show-stopper if we can't find a way to reconcile the general use case that it represents (i.e., we don't just need a fix for contrib.messages -- we need to explain how/why the problem