Re: is_valid as property

Hello Sven, > On 12 Oct 2016, at 12:21, Sven R. Kunze wrote: > > Am Dienstag, 11. Oktober 2016 17:51:20 UTC+2 schrieb Aymeric Augustin: > > The API for displaying errors is form.errors. > > If the documentation implies otherwise, please accept my apologies! > > No problem. I now did read the

Re: is_valid as property

I agree with Tim. I don't think it's overly necessary. FWIW, form.validate actually is form.full_clean. Am Dienstag, 11. Oktober 2016 19:04:51 UTC+2 schrieb Tim Graham: > > I don't think requiring every Django project to rewrite their views from: > > if form.is_valid(): > > to > > form.validate(

Re: is_valid as property

Am Dienstag, 11. Oktober 2016 17:51:20 UTC+2 schrieb Aymeric Augustin: > > On 11 Oct 2016, at 14:52, Sven R. Kunze > > wrote: > > I did never say "let's do business logic in templates". AFAIK, > *displaying* errors (or preparing for it HTML-structure-wise) requires > *knowing* whether a form is

Re: is_valid as property

I don't think requiring every Django project to rewrite their views from: if form.is_valid(): to form.validate() if form.is_valid: is practical. About changing form.errors not to validate the form, I'm not sure there's much benefit there either. When writing tests, I often write: self.asser

Re: is_valid as property

If we choose to move the call to full_clean from errors to is_valid with a deprecation period, maybe we could rename is_valid to validate. is_valid could be kept as a property, raising error if called before validate like error would be after the change. 2016-10-11 17:50 GMT+02:00 Aymeric Augusti

Re: is_valid as property

> On 11 Oct 2016, at 14:52, Sven R. Kunze wrote: > > I did never say "let's do business logic in templates". AFAIK, displaying > errors (or preparing for it HTML-structure-wise) requires knowing whether a > form is invalid or not. The API for displaying errors is form.errors. If the documenta

Re: is_valid as property

On Tue, Oct 11, 2016 at 04:28:40PM +0200, ludovic coues wrote: > First time you access form.errors, it will call form.full_clean. > > But after looking at the code and not simply reading the doc, I agree > that is_valid should be a property. After the first call to is_valid, > the value won't chan

Re: is_valid as property

First time you access form.errors, it will call form.full_clean. But after looking at the code and not simply reading the doc, I agree that is_valid should be a property. After the first call to is_valid, the value won't change, even if a field is set to a non-valid value. 2016-10-11 15:49 GMT+02

Re: is_valid as property

Am Dienstag, 11. Oktober 2016 15:03:21 UTC+2 schrieb ludovic coues: > > If I remember correctly, form.is_valid do the actual form validation > and return false in case of error. > I don't know what counts as "actual form validation" but form.is_valid is "just" a wrapper on form.errors which is

Re: is_valid as property

If I remember correctly, form.is_valid do the actual form validation and return false in case of error. In your template, you can use {% if form.errors %} to check if the form has any error. It's a dict with field as key and list of errors as value. 2016-10-11 14:52 GMT+02:00 Sven R. Kunze : > Am

Re: is_valid as property

Am Dienstag, 11. Oktober 2016 14:16:50 UTC+2 schrieb Aymeric Augustin: > > Hello Sven, > > On 11 Oct 2016, at 14:07, Sven R. Kunze > > wrote: > > I took a sample of 4 of my colleagues and asked them what the problem with > expressions like {% if form.is_valid %} is. They have no idea. They said

Re: is_valid as property

Am Dienstag, 11. Oktober 2016 14:11:28 UTC+2 schrieb Sven R. Kunze: > > Am Donnerstag, 29. September 2016 21:25:44 UTC+2 schrieb Sjoerd Job > Postmus: >> >> Thinking of an alternative route: >> >> It seems to me that the default `method.__bool__` is undesirable in >> Jinja2 templates. I do not

Re: is_valid as property

Hello Sven, > On 11 Oct 2016, at 14:07, Sven R. Kunze wrote: > > I took a sample of 4 of my colleagues and asked them what the problem with > expressions like {% if form.is _valid %} is. They have no > idea. They said "it might not make sense in some cases but when it makes >

Re: is_valid as property

Am Donnerstag, 29. September 2016 21:25:44 UTC+2 schrieb Sjoerd Job Postmus: > > 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`-s

Re: is_valid as property

Am Donnerstag, 29. September 2016 22:05:43 UTC+2 schrieb Aymeric Augustin: > > 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

Re: is_valid as property

Hi everybody, On Fri, Sep 30, 2016 at 09:04:32AM +0300, Shai Berger wrote: > Hi Sven, > > On Thursday 29 September 2016 22:09:27 Sven R. Kunze wrote: > > > > Am Donnerstag, 29. September 2016 20:26:54 UTC+2 schrieb Aymeric Augustin: > > > > > Generally speaking, properties are expected to be ch

Re: is_valid as property

Hi Sven, On Thursday 29 September 2016 22:09:27 Sven R. Kunze wrote: > > Am Donnerstag, 29. September 2016 20:26:54 UTC+2 schrieb Aymeric Augustin: > > > Generally speaking, properties are expected to be cheap and methods can be > > expensive. In my opinion, for lack of a better guideline, we sh

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 discussing here! -- Aym

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 `Funct

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: > # will always be

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 the underlying func

Re: is_valid as property

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 the underlying function. Or `__bool__` raising an error? [1] I myself am a fan of erro

Re: is_valid as property

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: > # will always be executed > # as it is always true This is perhaps the strongest argument in this discussion but I’

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 is

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 w

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 eas

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 > https://groups.google.com/forum/#!searchin/django-developers/i

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 rem