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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
26 matches
Mail list logo