is_valid as property

Good afternoon, I would like to follow up on https://groups.google.com/forum/#!searchin/django-developers/is_authenticated$20as$20property%7Csort:relevance/django-developers/7k6Z8JxKH5Q/RoNKv66xcAMJ with regards to Form.is_valid. It's is not as security relevant as is_authenticated but the

Re: is_valid as property

I don't think the same argument applies because no one (I hope) is calling form.is_valid() in templates. On Thursday, September 29, 2016 at 9:38:07 AM UTC-4, Sven R. Kunze wrote: > > Good afternoon, > > I would like to follow up on >

has_changed as property

Good afternoon, I would like to follow up on https://groups.google.com/forum/#!searchin/django-developers/is_authenticated$20as$20property%7Csort:relevance/django-developers/7k6Z8JxKH5Q/RoNKv66xcAMJ with regards to Form.has_changed. It's is not as security relevant as is_authenticated but the

Re: Form.Media: render inline css/js

Thanks for the heads up, a similar ticket has been closed as wontfix, because it isn't compatible with CSP: https://code.djangoproject.com/ticket/13978 While I'm all against inline scripts, I have a use case which seems be legitimate:

Re: Form.Media: render inline css/js

I'm not exactly sure what your proposal entails. Could you give some psuedo-code to demonstrate what you have in mind? By the way, there is some discussion that it might be best to replace the Media class, although it's not entirely clear how to do that:

Re: has_changed as property

Unless there are different arguments for has_changed vs. is_valid, I suggest we discuss both attributes on the nearly identical "is_valid as property" thread. On Thursday, September 29, 2016 at 9:40:38 AM UTC-4, Sven R. Kunze wrote: > > Good afternoon, > > I would like to follow up on >

Re: has_changed as property

That's works for me. Am Donnerstag, 29. September 2016 15:56:18 UTC+2 schrieb Tim Graham: > > Unless there are different arguments for has_changed vs. is_valid, I > suggest we discuss both attributes on the nearly identical "is_valid as > property" thread. > > On Thursday, September 29, 2016 at

Re: is_valid as property

#1. Regarding templates, one of the arguments for the previous change was: Django 1.8 worsens the situation significantly: {% if request.user.is_authenticated %} does the right thing in a Django template but is a security vulnerability in a Jinja2 template! #2. There was an inconsistency

Re: is_valid as property

Am Donnerstag, 29. September 2016 15:52:00 UTC+2 schrieb Tim Graham: > > I don't think the same argument applies because no one (I hope) is calling > form.is_valid() in templates. > Could you elaborate why this only plays a role with templates? So, as it turns out I ran grep on our code and

Re: has_changed as property

One additional note: has_changed is a lot more subtle than is_valid because it is used less often than is_valid (checked by grepping through our sources). Am Donnerstag, 29. September 2016 17:18:35 UTC+2 schrieb Sven R. Kunze: > > That's works for me. > > Am Donnerstag, 29. September 2016

Re: is_valid as property

Am Donnerstag, 29. September 2016 18:55:37 UTC+2 schrieb Tim Graham: > > #1. Regarding templates, one of the arguments for the previous change was: > > Django 1.8 worsens the situation significantly: > > {% if request.user.is_authenticated %} > > does the right thing in a Django template but

Re: Challenge teaching Django to beginners: urls.py

I have a feeling this is orthogonal to the original request. The original request/problem was "regex is hard". Your response answers/solves "the URL definition is somewhere different from the view definition". Both issues are realistic [1], and orthogonal. [1]: I myself have great aversion to the

Re: Challenge teaching Django to beginners: urls.py

Hi all, I already solved the problem for hard urls writing/reading. Please take a look, maybe you are interested in it :) https://github.com/phpdude/django-macros-url It provides simple & clear way to build your strong urls patterns. Example from project page is attached urlpatterns =

Re: Challenge teaching Django to beginners: urls.py

Hi Emil, that's not only a teaching issue. Also experienced devs struggle with this way to declaring URLs. Internally, we developed a UrlMixin for our view classes such as: class MyView(UrlMixin, View): url_pattern = r'^bar/foo/$' view_name = 'my-index' # rest of view code

Re: is_valid as property

On 29 Sep 2016, at 20:26, Sjoerd Job Postmus wrote: > Replacing functions with properties will create a lot of churn in the people > using the mentioned functions. > > Another approach might be to wrap these functions in a class with `__call__` > and `__bool__` both calling

Re: Challenge teaching Django to beginners: urls.py

Hi Emil, that's not only a teaching issue. Also experience devs struggle with this way to declaring URLs. Internally, we developed a UrlMixin for our view classes such as: class MyView(UrlMixin, View): url_pattern = r'^bar/foo/$' view_name = 'my-index' # rest of view code

Re: is_valid as property

Hi Aymeric, thanks for your ideas. Am Donnerstag, 29. September 2016 20:26:54 UTC+2 schrieb Aymeric Augustin: > > Hello, > > On 29 Sep 2016, at 19:57, Sven R. Kunze > wrote: > > #3 "Errors should never pass silently." > > Which they do if you write: > > if form.is_valid: >

Re: Challenge teaching Django to beginners: urls.py

Am Donnerstag, 29. September 2016 20:42:47 UTC+2 schrieb Sjoerd Job Postmus: > > I have a feeling this is orthogonal to the original request. > > The original request/problem was "regex is hard". > Your response answers/solves "the URL definition is somewhere different > from the view

Re: is_valid as property

On 29 Sep 2016, at 21:09, Sven R. Kunze wrote: > But independently, I still miss the point why {% if form.is > _valid %} cannot be a problem in Jinja2? If you’re writing that kind code in templates, you have much, much bigger problems than what we’re

Re: is_valid as property

Thinking of an alternative route: It seems to me that the default `method.__bool__` is undesirable in Jinja2 templates. I do not know Jinja2 well enough, but maybe they could benefit from a patch where `if`-statements give a warning/error when the _expression_ is a callable (with the default