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: Javascript Templating Package

Hi Daniel, This is a separate idea. Instead of relying on JSON dumps, we actually generate an entire JS script via the engine. The flow is along the lines of: > Client makes request > Django receives request and renders an HTML page which it passes to the client. > The given HTML page has a sc

Re: Javascript Templating Package

Hi Nick, I'm not sure what kind of generation are you suggesting. What I've used a couple of times is creating a template tag to convert a json-like data structure in the context to a javascript object, so in the template I have something like this in a

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

Javascript Templating Package

Hi Everyone, We were tasked at work some time ago with tidying up a legacy Django project. Part of the projects JS relied heavily on Django variables and settings and we were seeing frequent large variable JSON dumps in the templates. We cleaned this up and ended up designing a small package w

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: Autocomplete in Django 1.11: Widget in Forms Library?

On Tue, Oct 11, 2016 at 2:20 PM, Johannes Hoppe wrote: > > At the current point I don't see how we could add a more generic widget to > Django outside of the admin. This would require ether a manual registration > of models as autocomplete light does it, or another approach that doesn't > rely on

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: Autocomplete in Django 1.11: Widget in Forms Library?

Hi there! Regarding reusing the admin widget: I would advice highly against it. It made for the admin and requires models to be registered there. It would be better to use django-select2, which is where the autocomplete_fields are originating from. At the current point I don't see how we could

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