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 much, much bigger
> problems than what we’re discussing here!
>
>
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 sense, it doesn't
look very terrible me".
So, what's the real problem here?
Cheers,
Sven
PS: as said, we don't use it yet but we shouldn't it should be noted
somewhere as it
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/f37da113-7fbc-4c94-9e23-69a42741a4ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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`-statements give a warning/error when the expression > is a callable (with the default `FunctionType.__bool__`? > > This would solve the issue not just for the methods you mention, but more > in general. > > [Or maybe Python itself should have that warning/error?] > > Does that make sense? > I don't know if it is possible for Python to warn about this. I create an issue on python-ideas. But your idea seems interesting (at least from a development point of view). -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4386417c-fa74-4388-88e5-cb896b90f73a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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
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 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 Django cache. The only way I see at the moment, is if Widget.render() would be aware of the request. This way one could use the session as a persistent storage. This is a bigger design decision tho. On Tuesday, September 20, 2016 at 12:51:24 PM UTC+2, guettli wrote: > > I am happy that there will be support for autocomplete in the admin in > 1.11, if this issue/pull-request gets resolved: > > https://code.djangoproject.com/ticket/14370 > > https://github.com/django/django/pull/6385/ > > I looked at the changes of the docs of this pull request. > > It seems that only the contrib module "admin" gets improved. > > Is it planed to add an autocomplete widget in the django forms library? > > > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5ffe26b8-11d0-47c9-afab-3d7512adc3e5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 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 `FunctionType.__bool__`? >> >> This would solve the issue not just for the methods you mention, but more >> in general. >> >> [Or maybe Python itself should have that warning/error?] >> >> Does that make sense? >> > > I don't know if it is possible for Python to warn about this. I create an > issue on python-ideas. > > But your idea seems interesting (at least from a development point of > view). > https://mail.python.org/pipermail/python-ideas/2016-October/042782.html -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9fa02501-252f-474f-8956-6467cf7ecd35%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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
> "it might not make sense in some cases but when it makes sense, it doesn't
> look very terrible me”.
>
>
> Can you show a non-contrived example, predating this discussion, of a
> situation where this pattern make sense?
>
For displaying some error indicators, changing backgrounds to signal colors
(like red), etc. I don't know what counts as a non-contrived example to you.
>
> So, what's the real problem here?
>
>
> The real problem is that templates aren’t the correct place to implement
> business logic such as form validation.
>
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.
When there's some logic to do, that's fine. But when some developer
requires a simple boolean flag to know whether a form is valid or not, why
shouldn't he use form.is_valid? That looks to me like making things more
complicated than necessary.
Also, think about GET forms + AJAX which do not POST after redirect at all
(e.g. search form + result table in separate AJAX containers). There you
will re-use the same template for success and failure.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/4ffb3d8c-43fa-4bc1-9762-eae79334af28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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 Django cache. > In DAL v3 there is no need for model registration. Autocomplete widgets do take a URL as argument though. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALC3Kaf8_E6eeHatLn2kn1KO%3Dp3Bwwm%3DO6d5Z0DE_81Qwb8Zww%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
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 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 "it
>> might not make sense in some cases but when it makes sense, it doesn't look
>> very terrible me”.
>>
>>
>> Can you show a non-contrived example, predating this discussion, of a
>> situation where this pattern make sense?
>
>
>
> For displaying some error indicators, changing backgrounds to signal colors
> (like red), etc. I don't know what counts as a non-contrived example to you.
>
>
>>
>>
>> So, what's the real problem here?
>>
>>
>> The real problem is that templates aren’t the correct place to implement
>> business logic such as form validation.
>
>
>
> 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.
>
> When there's some logic to do, that's fine. But when some developer requires
> a simple boolean flag to know whether a form is valid or not, why shouldn't
> he use form.is_valid? That looks to me like making things more complicated
> than necessary.
>
>
> Also, think about GET forms + AJAX which do not POST after redirect at all
> (e.g. search form + result table in separate AJAX containers). There you
> will re-use the same template for success and failure.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4ffb3d8c-43fa-4bc1-9762-eae79334af28%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
Cordialement, Coues Ludovic
+336 148 743 42
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAEuG%2BTZ7aFginSqg0aOrNTTH6CbneO3AXt6QSUvwafCfx01%2B9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
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 which allowed us to generate Javascript files through the Django templating engine when requested by the client. Since then we've started finding ourselves thinking about using this package more and more. So I was wondering, is this something that the community would be interested in? It's not open source yet but we're considering opening up the particular package (not least so its more available for us). If it's not at all of interest, why? Is there a big disadvantage to generating Javascript through the templating engine? (assume you, and not the client, control the variables going in. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/04d4d42d-3bfa-47c6-9ac7-e9d801de9286%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 a *property*. cf. https://github.com/django/django/blob/3c447b108ac70757001171f7a4791f493880bf5b/django/forms/forms.py#L164 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bc3d0c3a-024a-4149-afde-6f34c99f53d2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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: 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 script tag which requests a javascript file from our server. > Django receives this request and, instead of serving a static javascript file, renders a javascript file via the templating engine which it then passes to the client. This allows us to have more control over the client side scripts based on what is happening server side. It's a bit niche - but it cleared up a lot of the legacy JS held in massive script tags which were overly wasteful and required a lot of tampering based on server side variables. On Tue, Oct 11, 2016 at 3:11 PM Daniel Moisset wrote: > 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
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:00 Sven R. Kunze : > 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 a property. > > cf. > https://github.com/django/django/blob/3c447b108ac70757001171f7a4791f493880bf5b/django/forms/forms.py#L164 > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/bc3d0c3a-024a-4149-afde-6f34c99f53d2%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- Cordialement, Coues Ludovic +336 148 743 42 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEuG%2BTY-SjFvX8TgT%3Dd57fX0Z6P_bkp3nfLTUmRWKiC-US-qrQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
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 change, even if a field is set to a non-valid value. Personally, I'd argue that the opposite should be true; is_valid should remain a method, and instead, we should change errors to no longer trigger full validation on first access. One possibility which would make sense to me would be that form.is_valid() could be the only supported way to trigger full validation, and form.errors could raise an error if it's accessed before calling is_valid first. The reasons I see for this change have been articulated pretty clearly by several people in this thread already... Of course, this would have to go through a full deprecation period, since the current behavior of form.errors is documented [0]... Cheers, Michal [0]: https://docs.djangoproject.com/en/1.10/ref/forms/api/#django.forms.Form.errors -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20161011143736.GA12099%40konk.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
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 documentation implies otherwise, please accept my apologies! -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/810B668F-D4D3-4C39-90CF-7357DF029921%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
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 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 invalid or not. > > > The API for displaying errors is form.errors. > > If the documentation implies otherwise, please accept my apologies! > > -- > Aymeric. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/810B668F-D4D3-4C39-90CF-7357DF029921%40polytechnique.org. > > For more options, visit https://groups.google.com/d/optout. -- Cordialement, Coues Ludovic +336 148 743 42 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEuG%2BTbhSrvLdbBmBPMoXa6NZ1dT4bs70QEg8VHFR%3DT6rVb5Dw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
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.assertEqual(form.errors, {...}) without calling is_valid().
On Tuesday, October 11, 2016 at 11:58:50 AM UTC-4, ludovic coues wrote:
>
> 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 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 invalid or not.
> >
> >
> > The API for displaying errors is form.errors.
> >
> > If the documentation implies otherwise, please accept my apologies!
> >
> > --
> > Aymeric.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "Django developers (Contributions to Django itself)" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to django-develop...@googlegroups.com .
> > To post to this group, send email to django-d...@googlegroups.com
> .
> > Visit this group at https://groups.google.com/group/django-developers.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/django-developers/810B668F-D4D3-4C39-90CF-7357DF029921%40polytechnique.org.
>
>
> >
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
>
> Cordialement, Coues Ludovic
> +336 148 743 42
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/e9660388-1ea1-4c6a-9de6-12ef392eab91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
