Re: is_valid as property

ng error if called before >> validate like error would be after the change. >> >> 2016-10-11 17:50 GMT+02:00 Aymeric Augustin >> <aymeric@polytechnique.org>: >> > On 11 Oct 2016, at 14:52, Sven R. Kunze <srk...@gmail.com> wrote: >> > &g

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 <srk...@gmail.com > > wrote: > > I did never say "let's do business logic in templates". AFAIK, > *displaying* errors (or preparing for it HTML-st

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

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 <srk...@gmail.com > > wrote: > > I took a sample of 4 of my colleagues and asked them what the problem with > expressions like {% if

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 undesira

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

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 <srk...@gmail.com > > wrote: > > But independently, I still miss the point why {% if form.is_valid %} > cannot be a problem in Jinja2? > > >

Re: Challenge teaching Django to beginners: urls.py

move the URL as well and vice versa. Put it differently, it makes no sense to separate URl and view in different locations. That's at least our experience while doing Web-based applications and APIs for years. Best, Sven -- You received this message because you are subscribed to the Google Gr

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 <srk...@gmail.com > > wrote: > > #3 "Errors should never pass silently." > > Which

Re: Challenge teaching Django to beginners: urls.py

That's all we need to do in order to define a *view with a working url pattern*. Reverse works with the optional view_name or by reversing the class itself. Maybe, the simplification of your proposal could be explored by providing such a UrlMixin first. Best, Sven -- You received this message

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

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: 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. Septembe

Re: has_changed as property

Thursday, September 29, 2016 at 9:40:38 AM UTC-4, Sven R. Kunze wrote: >> >> 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/7k6Z8Jx

has_changed as property

but the remaining arguments of "is_authenticated as property" still hold. I also suggest the usage of CallableBool as a good temporary backwards-compatibility measure. Best Sven NOTE: this one hid an especially annoying bug (also performance-wise) in production for us. -- You received th

is_valid as property

but the remaining arguments of "is_authenticated as property" still hold. I also suggest the usage of CallableBool as a good temporary backwards-compatibility measure. Best Sven -- You received this message because you are subscribed to the Google Groups "Django developers (Contribu

Support of model_object.delete(cascade=True)

/ticket/26664 Would this be valuable addition to Django? Best, Sven -- 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, sen

Re: is_authenticated as property

Am Montag, 25. April 2016 10:38:23 UTC+2 schrieb Florian Apolloner: > > Absolutely not, what are you basing your justification on? > The fact that I know real cases where this was a security issue. I'd rather have a backwards incompatibility than a security hole. But that may just be me. One

Re: Vendoring Select2

Hi Johannes, Am Sonntag, 24. April 2016 10:16:53 UTC+2 schrieb Johannes Hoppe: > > Hi Sven, > > you are right. For this particular case select2 would be an ill advice. > But I didn't initially add support for m2m fields. I just added it later to > my pull-requested, since it

Re: Vendoring Select2

widget. That's where selectable comes in. The presentation of the selection *as a list* appears to be less confusing. Just wanted to share this with you even if you might already have decided to use select2. Sven -- You received this message because you are subscribed to the Google Groups

Re: is_authenticated as property

Am Montag, 11. April 2016 18:57:46 UTC+2 schrieb Tim Graham: > > Do you think the backwards incompatibility is justified here or do you > prefer some other solution? > I for one think it is justified here. -- You received this message because you are subscribed to the Google Groups "Django

Re: Django template 'if ... is' feature design

I couldn't see a good use-case, though. :( > I don't see much benefit to your proposal of limiting its usage to > comparing boolean/None values. > Neither do I, given that "== True", "== False" and "== None" will do the trick. Sven -- You r

Re: Django template 'if ... is' feature design

I didn't know that exactly this was a deliberate choice. I always got the impression that Django tries to boil down the feature set of its template engine for very good reasons (which I agree with). Sven -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Make template caching a feature of the Django template engine

che but a cache does not need to be perfect after all and the increased memory footprint would not even matter in development. """ Do you think that's a feasible solution? Sven -- You received this message because you are subscribed to the Google Groups "Django develope

Re: Form field labels change proposal

Good evening everybody. :) I would like to reference this ticket: https://code.djangoproject.com/ticket/26497#comment:11 It appears we stumbled over this issue as well while designing a new model form. Quoting my comment from the ticket: Would it make sense to separate concepts here? 1)

Re: Django template 'if ... is' feature design

Good evening everybody. That's my first post here, so let's how this works. :) This particular discussion caught my sight as it might introduce something really "low-level" functionality into the template engine. I can contribute here to the "design consideration" that from my experience

Re: Form field labels change proposal

It has been said before but CSS was made for this and we should not mix content with design. I'd like to see this implemented with or without the deprecation path. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django