Re: Feature proposal: escape hatch for colliding template syntax in django templates

> If we're going to do this, could we also look at deprecating the > 'templatetag' template tag? There are a couple cases a 'verbatim' tag > wouldn't cover that 'templatetag' wouldn't, but I'm kinda hard-pressed > to think of when they'd ever come up in reality. +1 for this. I for one don't even

Re: Feature proposal: escape hatch for colliding template syntax in django templates

On 20/10/10 02:40, Stephen Kelly wrote: Sorry. Sent too early. All thumbs today. Consider these examples: {% verbatim "%} %}" %} (That is, "%} %}" in a verbatim-no-end tag) {% verbatim %} %} %} {% endverbatim %} (That is, " %} %} " wrapped in verbatim tags) The current lexer uses regexps to

Re: new class based views

Awesome, thank you! I've asked about @login_required and class based views in django-users, and I'd like to ask here: are something like LoginRequiredMixin's planned? -- Best Regards, Valentin Golev Lead Developer r00, http://r00.ru http://valyagolev.net +7 921 789 0895, avaiable 12:00-18:00

Ordering Check in django/core/management/validation.py

Hi, I'm not sure I'm following protocol here, but here it goes... django/core/management/validation.py, both in the current trunk and in 1.2.3 It says in the accompanying comment: # Skip ordering in the format field1__field2 (FIXME: checking # this format would

Re: new class based views

On Wed, Oct 20, 2010 at 6:01 PM, Valentin Golev wrote: > Awesome, thank you! > > I've asked about @login_required and class based views in > django-users, and I'd like to ask here: are something like > LoginRequiredMixin's planned? No, nothing like that is planned. This is a

Re: Ordering Check in django/core/management/validation.py

On Wed, Oct 20, 2010 at 6:43 PM, Klaas van Schelven wrote: > Hi, > > I'm not sure I'm following protocol here, but here it goes... The best way to report this is to open a ticket [1] which describes the problem in detail (which is what you've done here). This ensure

Re: new class based views

As far as I know, I can just say: @login_required class MyView(View): # ... since it will wrap __init__ I need either to create a decorator for decorators: @on_dispatch(login_required) class MyView(View): or decorate result of MyView().as_view(). Maybe I'm wrong. I think it will be great

Re: new class based views

Almost everything I'm talking about right now is from this thread: http://groups.google.com/group/django-users/browse_frm/thread/5239e284b5c285d5/a2676f257d37cf85#a2676f257d37cf85 ("login_required and new class based views" in django-users in case the link doesnt work.) -- Best Regards,

Re: new class based views

On Wed, Oct 20, 2010 at 7:05 PM, Valentin Golev wrote: > As far as I know, I can just say: > > @login_required > class MyView(View): >   # ... > > since it will wrap __init__ > > I need either to create a decorator for decorators: > @on_dispatch(login_required) > class

Re: new class based views

I think class decorator for views only is a great idea, because it will be: a) just like with old view functions decorators b) does not require any method overrides/imports into urls.py/explicit transformations in views.py I'd like Django to have a decorator for turning old decorators into

Re: Feature proposal: escape hatch for colliding template syntax in django templates

Am 20.10.2010 um 10:40 schrieb Andrew Godwin: > On 20/10/10 02:40, Stephen Kelly wrote: >> Sorry. Sent too early. All thumbs today. Consider these examples: >> >> {% verbatim "%} %}" %} >> >> (That is, "%} %}" in a verbatim-no-end tag) >> >> {% verbatim %} %} %} {% endverbatim %} >> >> (That

Re: Model proxy instance does not equal the respective model instance

Continuing from... http://code.djangoproject.com/ticket/14492 > the real issue here is "What is a Proxy", and "what is equality" I agree, that is the real issue. I based most of my reasoning off of what the docs already state in that a proxy model can be written to extend the behavior of the

Re: new class based views

On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote: > A class decorator (and/or a wrapper function for turning decorators > into class decorators) is also an interesting idea. An argument against this is "one way to do it". If I look at a class and want to know what decorators are

Re: new class based views

On 20 October 2010 15:59, Luke Plant wrote: > On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote: > >> A class decorator (and/or a wrapper function for turning decorators >> into class decorators) is also an interesting idea. > > An argument against this is "one

Re: new class based views

Well, since we are already using class Mixins for extending View functionality, we can try to turn decorators into mixins. Having two ways to add some functionality to class (decorators and mixins) can be somewhat uncomfortable. I had some doubts if mixins can act as a "wrappers" to defined

Re: new class based views

On Wed, Oct 20, 2010 at 9:59 PM, Luke Plant wrote: > On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote: > >> A class decorator (and/or a wrapper function for turning decorators >> into class decorators) is also an interesting idea. > > An argument against this is

Re: new class based views

Created a ticket for this: http://code.djangoproject.com/ticket/14512 On 20 October 2010 16:13, Russell Keith-Magee wrote: > On Wed, Oct 20, 2010 at 9:59 PM, Luke Plant wrote: >> On Wed, 2010-10-20 at 19:25 +0800, Russell Keith-Magee wrote: >> >>>

Re: Ordering Check in django/core/management/validation.py

http://code.djangoproject.com/ticket/14513 Now give me my bonus points :-) On Oct 20, 1:05 pm, Russell Keith-Magee wrote: > On Wed, Oct 20, 2010 at 6:43 PM, Klaas van Schelven > > wrote: > > Hi, > > > I'm not sure I'm following protocol

Proposal: A better way to handle unic�de in messag es, etc

I was trying some things out, and I noticed that it isn't actually possible (without using a char-code and converting it) to put something like ° (degree symbol) into a "message". Example: this code: messages.info(request, request.GET.get('symbol')) with this URL:

contrib.staticfiles app concerns

Hi, first of all, sorry for chiming in so late. It seems like this has been discussed in May, already, but I didn't follow the discussion back then. Today the staticfiles contrib app was committed to trunk. This got me wondering: Wasn't there recently a discussion about how "contrib" is a bad

Re: new class based views

On Wed, 2010-10-20 at 16:05 +0200, Łukasz Rekucki wrote: > OTOH, it's annoying to have to write an dispatch() method with a super > inside (which effectively does nothing), just to apply a decorator. That's a good point I hadn't thought of, as are Russell's other points. Just to put it on the

Re: Proposal: A better way to handle unicode in messages, etc

On Wed, 2010-10-20 at 09:50 -0700, Yo-Yo Ma wrote: > I was trying some things out, and I noticed that it isn't actually > possible (without using a char-code and converting it) to put > something like ° (degree symbol) into a "message". > > Example: > > this code: > messages.info(request,

Gentle Proposal: add 'render' shortcut in 1.3

Hi all, I'm talking about this ticket: http://code.djangoproject.com/ticket/12816 With class-based views landed and the deprecation of django.views.generic.simple (and direct_to_template in particular) there won't be simple and undeprecated shortcut for render_to_response. So please add the

Re: contrib.staticfiles app concerns

Hi Waldemar, On Oct 20, 1:40 pm, Waldemar Kornewald wrote: [snip] > However, what staticfiles does has almost nothing to do with "bigger > project" asset management. Just look at the features grid on > djangopackages (disclaimer: I'm the author of django-mediagenerator >

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

On Wed, Oct 20, 2010 at 1:48 PM, Mikhail Korobov wrote: > So please add the 'render' shortcut in 1.3. It's one of the things on my list. If you'd like to make it happen faster, a patch + tests would make it a no-brainer for me. Jacob -- You received this message

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

That's great! I'll mark the ticket as assigned for me then. There is an unresolved question in the ticket: "The only hesitation is the relationship with #12815; we should resolve that decision before committing anything for this ticket." #12815 is about introducing TemplateResponse. Is the patch

Re: contrib.staticfiles app concerns

I agree with Carl, > Staticfiles has a very specific, well-defined purpose (collecting media > files from apps), which fills a major hole in the Django "story" for > reusable apps. IMHO contrib apps should have the following characteristics (and probably more): * Solves a problem that can be

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

2010/10/20 Mikhail Korobov : > There is an unresolved question in the ticket: "The only hesitation is > the relationship with #12815; we should resolve that decision before > committing anything for this ticket." > > #12815 is about introducing TemplateResponse. Is the

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

On 20 October 2010 21:57, Jacob Kaplan-Moss wrote: > 2010/10/20 Mikhail Korobov : >> There is an unresolved question in the ticket: "The only hesitation is >> the relationship with #12815; we should resolve that decision before >> committing anything

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

I think the correct ticket is http://code.djangoproject.com/ticket/9081 and it is in 'almost-wontfix' state now. Yes, it's a great time to either move it to wontfix or mark as accepted and implement alongside with the render shortcut. On 21 окт, 02:05, Łukasz Rekucki wrote: >

Re: contrib.staticfiles app concerns

On Wed, Oct 20, 2010 at 3:04 PM, Waldemar Kornewald wrote: > I wish that were the case. The staticfiles documentation says: > > """ > Remember to run :djadmin:`collectstatic` when your media changes; > the view only serves static files that have been collected. > """ I

Re: Model proxy instance does not equal the respective model instance

Speaking on a semantic level, a "proxy" is a stand-in acting on behalf of (or in place of) another entity. There is an implied near- equivalence, but inherent in the idea of a proxy is that it is *not* the same as the original. As in the case of assigning a proxy to vote for you in corporate

Re: contrib.staticfiles app concerns

Hi Waldemar, On Oct 20, 4:04 pm, Waldemar Kornewald wrote: > In what way does staticfiles make writing reusable apps easier? It > merely collects apps' "static" folders. The same thing could be > achieved by defining a simple standard: > "Put media files in the 'media'

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

On 10/20/2010 11:51 PM, Mikhail Korobov wrote: #12815 is about introducing TemplateResponse. Is the patch with 'render' shortcut returning just HttpResponse acceptable? I think that TemplateResponse is less useful after class-based views make their way into trunk so 'render' shortcut shouldn't

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

Hi Ivan! On 21 окт, 03:00, Ivan Sagalaev wrote: > > Wait!!! > > Sorry… Hello everyone :-) > > If I remember correctly TemplateResponse was solving a problem of some > middleware wanting to mess with a view context before it's baked into > final string representation.

Admin sends out potentially harmful m2m_changed signals

I'd like to call attention to ticket #6707 [1], which deals with the implementation of ReverseManyRelatedObjectsDescriptor.__set__. Specifically, the problem is that the current implentation takes a very efficient "clear everything and add all the keys back in" approach to managing these

Re: contrib.staticfiles app concerns

Hi Carl, On Wed, Oct 20, 2010 at 10:53 PM, Carl Meyer wrote: > Hi Waldemar, > > On Oct 20, 4:04 pm, Waldemar Kornewald wrote: >> That's a funny combination of tools. :) >> You don't really need django-staticfiles because in your case >>

Re: contrib.staticfiles app concerns

On Wed, Oct 20, 2010 at 10:13 PM, Jacob Kaplan-Moss wrote: > On Wed, Oct 20, 2010 at 3:04 PM, Waldemar Kornewald > wrote: >> I wish that were the case. The staticfiles documentation says: >> >> """ >> Remember to run :djadmin:`collectstatic` when your

#14512: Decorating class based views (was Re: new class based views)

On 20 October 2010 19:42, Luke Plant wrote: > On Wed, 2010-10-20 at 16:05 +0200, Łukasz Rekucki wrote: > >> OTOH, it's annoying to have to write an dispatch() method with a super >> inside (which effectively does nothing), just to apply a decorator. > > That's a good point

Re: Proposal: A better way to handle unic�de in me ssages, etc

On Thu, Oct 21, 2010 at 12:50 AM, Yo-Yo Ma wrote: > I was trying some things out, and I noticed that it isn't actually > possible (without using a char-code and converting it) to put > something like ° (degree symbol) into a "message". Sure. Sounds like a bug to me. If

Re: new class based views

On Thu, Oct 21, 2010 at 1:42 AM, Luke Plant wrote: > On Wed, 2010-10-20 at 16:05 +0200, Łukasz Rekucki wrote: > >> OTOH, it's annoying to have to write an dispatch() method with a super >> inside (which effectively does nothing), just to apply a decorator. > > That's a good

Re: contrib.staticfiles app concerns

On Thu, Oct 21, 2010 at 2:40 AM, Waldemar Kornewald wrote: > Today the staticfiles contrib app was committed to trunk. This got me > wondering: Wasn't there recently a discussion about how "contrib" is a > bad idea and all apps should either be in core or live as separate >

Re: contrib.staticfiles app concerns

Ian, > I thought about this too and had a long thread on Twitter with jezdez about > staticfiles. It occurred to me that adding more apps to contrib was kind of a > bad idea. I know "everyone" uses admin etc. but I was of the understanding > that contrib apps are optional apps for django but

Re: Model proxy instance does not equal the respective model instance

I think that since Proxy models only affect the methods, properties and way the data is used (not the actual underlying data itself), it is appropriate to compare User and UserProxy as equal. To not treat them as equal, you will need to be sure that you never pass a UserProxy object to a 3rd party