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 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/024bd636-be28-4fd3-8a6f-d1a07f88b423%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 with other (less experienced) developers it that the difference of "is" and "==" is not quite easy to explain (as illustrated by this thread as well). So, I am not 100% convinced that "is" and "is not" is a valid use-case for a template language but I may miss some important piece here. However, given the docs and tests added in the patch, it seems the intended use-case for this kind of feature is to check for "is None", "is not None", "is True", "is not True" etc. Would it makes sense to hard-wire those specific use-cases instead? (Admittedly, even those can be implemented using "==".) -- 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/2e5471b6-2e0a-4098-8056-53787ba75b83%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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) *user-defined* verbose_name: Django should not touch it 2) *auto-generated* verbose_name: Django generates the verbose_name from the field's name In both cases, once the label of a form field is set, Django should only touch it (except on the designers behalf). *Deprecation phase*: a) make global capitalization optional via settings (or form variable) with True as default for status quo. b) auto-generated verbose_names are generated using a format string which can also be specified by a settings variable (or form variable). Default should result in current output (with the capitalization) c) disable global capitalization by default Does this makes sense? -- 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/94da855b-c159-4c17-a24f-16f843096ae7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Make template caching a feature of the Django template engine
Hi everybody, Tim pointed me to this discussion here and I support the overall goal. It accelerates development, especially when designing somewhat prettier Web pages. Quoting my quite naive approach from the issue tracker (https://code.djangoproject.com/ticket/26507#comment:2): """ I don't know if I would agree with the new title. Actually, I do not want to reload/replace the already loaded template. Looking at the source, I would say, we could make 'Loader.cache_key' respect the mtime of the first found template. So, they are two versions of the template in the cache 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 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/81c26c94-bc52-4220-afb4-abedd06e27d0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Django template 'if ... is' feature design
Am Donnerstag, 14. April 2016 21:04:04 UTC+2 schrieb Stephen: > > > As far as I understand from > > https://github.com/django/django/pull/6442 > > it it deliberate that the if tag exposes the entire implementation detail. > > Thanks for clarifying. 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 (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/89ae41f3-8be7-4b83-8e66-4b2aa26a3809%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Django template 'if ... is' feature design
Hi Tim, due to Stephen's response, my concerns are not valid. :) Still, my comments among your lines: Am Freitag, 15. April 2016 02:30:46 UTC+2 schrieb Tim Graham: > > Here are some examples of when the "is" operator isn't equivalent to "==". > > http://stackoverflow.com/questions/3647692/when-is-the-operator-not-equivalent-to-the-is-operator-python > It's true that "==" is not the same as "is". I just wanted to say that most sane cases are probably YAGNI. Especially in the light of the increased complexity for template users. > Preston (author of the patch to add the "is" operator [0]) indicated > support for "is" was necessary for template-based widget rendering [1]. I > haven't studied that patch closely, but maybe if you take a look you'll > understand why it's needed. > Mmm, 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 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/dbf49a98-1080-45a6-b7d9-c9f406cd39f0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 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/3d8ea847-5049-4b16-8462-c8eaf7bc2ce4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vendoring Select2
Hi, I hope I am not too late to the discussion (and I hope it's the right one). :) Am Mittwoch, 6. April 2016 15:42:58 UTC+2 schrieb Collin Anderson: - Why select2? I haven't heard any serious proposals of a different library to use. Internally, we had the same debate of upgrading our widgets for ForeignKey/ManyToMany, so I would like to share the current result with you. Unfortunately, we ended up with two different widgets: 1) django-selectable 2) select2 We found that select2 only makes sense for a *very very small number* of selected items but allows on-the-fly creation of items even for many-to-many relations. Thus, we use if for email address fields and tags: foreign keys but text input suffices for creation. On the other hand, if you need to distribute 800 users among 70 groups, where even half the users can be in a single group, then select2 is not the right 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 "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/6dc267db-390e-4587-a3fe-c391303655c0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 was only one line of code. And some people > would have found a usecase for It. > I look forward to it. > At the end this will be an optional feature and I wouldn't enable it for > users and groups ether. But than I don't have too. > Interesting. I didn't know one could choose a particular widget for foreign keys/m2m in the admin interface. Admittedly, I don't work on it regularly. > Thanks for the feedback! > You are welcome. :) 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, 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/bc197574-9819-4211-ba6d-711776362f7b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 might say that it's the responsibility of the developers and the testsuite/quality management. However, human make 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/c33de57c-72a2-45fd-94c8-3070f7ea85b3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Support of model_object.delete(cascade=True)
Hi everybody, That's my first proposal for Django, so I hope it's in the right shape. :) Even though we have on_delete=PROTECTED on several models fields for a very good reason, there are circumstances where we want to circumvent this restriction for a very good reason, too. And we are 110% sure that this is a safe operation. Tim already suggested to do this manually but this is very tedious for larger database structure as we have. We already wrote a generic function which provides that capability but we would appreciate a Django-bulitin functionality for this as we duplicate some Django-internal code. Note 1: overriding Model.delete() does not help as we needed it (this time) in a backward migration to clean up what has been created in a forward migration. Migrations don't expose model-overriden functions. Note 2: discussion started here: https://code.djangoproject.com/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, 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/1f9fc323-9911-4d79-bf02-0a669360eb8e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 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 (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/0b24ebd4-af4b-4a4c-8896-ea931411a06e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 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 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/0660b21a-3e8f-494b-9e63-394089249f9e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 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/7k6Z8JxKH5Q/RoNKv66xcAMJ >> >> with regards to Form.has_changed. >> >> It's is not as security relevant as is_authenticated 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 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/a0e98662-4356-4146-8e3a-6224bf12fcb8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 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 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/7k6Z8JxKH5Q/RoNKv66xcAMJ >>> >>> with regards to Form.has_changed. >>> >>> It's is not as security relevant as is_authenticated 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 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/1153143c-e375-4d01-803d-9fabf2cf75c8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 easily found a place where the programmer missed the "()" after is_valid. Regarding templates, I found no occurrences of "is_valid" nor "has_changed" in our templates so far but this might have other reasons as we don't have a very long history of templates until recently. Additionally, what's so wrong about using either function in templates? -- 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/74aee2cb-66d7-466a-8a79-c0e25d91a95e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 a security vulnerability
> in a Jinja2 template!
>
Ah, yes. I for one think that this is just a minor issue as changing the
underlying template engine is not done on a regular basis. But that might
just be me.
If it contributes as an argument, why not. I don't see anything wrong with
using is_valid/has_changed in templates especially when we need to display
field errors.
> #2. There was an inconsistency with the is_staff, is_active, is_superuser
> attributes and is_anonymous, is_authenticated as methods. I'm not sure what
> the inconsistency is with forms. Yes, there's an Form.is_bound property and
> an is_multipart() method but I don't see a need to convert all is_*()
> methods to properties.
>
>
> In my mind, the security ramifications were the main reason for the
> previous change, and I don't see those concerns here. Changing
> Form.is_valid() to a property seems like it would cause much more
> disruption across the Django ecosystem than the gain would be worth.
>
It's always the combination of several issues. Here are mine:
#1 Inconsistency
For newbies that's the hardest part; especially when now compared to
is_authenticated and other boolean attributes/properties even within Django.
#2 Wasted Effort
Also on a regular basis; which is quite problematic for commercial
projects. Focusing on the topic at hand is more important than such
technical details.
The mentioned dev who missed the "()" is one of our most experienced devs
and that mentioned piece of code is only 3 years old.
#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
#4 Django devs are not only Django devs
They are Python devs as well and usually Django as a single lib is not
enough. Especially Python devs expect things to work the same also across
most libs such as boolean attributes/properties.
You might not find them worth enough to warrant the trouble. I for one do,
hence the post. But it's not me to decide. :)
Some related thought: relating Django's past lifetime with its projected
future lifetime which still lies ahead, Django is still in its infancy.
So, I guess that any change no matter how "disruptive" for the sake of
consistency will eventually pay out. Latter generations will be grateful
not to distinguish between situations where they need "()" and where they
don't.
--
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/e36d0f0a-fee8-4340-9d8a-24402dd55b76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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
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.
Am Montag, 12. September 2016 22:32:45 UTC+2 schrieb Emil Stenström:
>
> Hi Djangonauts,
>
> I'm just back from my second year of teaching Django to absolute
> beginners. The course is a combination of HTML, CSS, Python, and Django,
> and after five days of coding they have a real live website that they can
> show to friends. It's always such a great experience to see the look in
> their eyes when they finally understand how they can tame Django to do what
> they want.
>
> There's one big thing that keeps tripping them up is urls.py. When
> specifying URL:s I get lots of questions about the regexes that they have
> to specify. First: there's a strange "r" in front of each line: r"regex".
> That means I will have to explain string escaping to them. Then there's the
> "^" and "$" signs, both which requires explaining regular expressions at
> length. Then there's [0-9]+ and finally there's the parenthesis around the
> regex. All in all, looking at URLs from a beginners perspective, they are a
> bunch of hieroglyphs, and very hard for beginners to grasp right away.
>
> I'm not suggesting that urls.py are changed for most users, I'm suggesting
> that *simple_url* method (name inspired by simple_tag) is added to
> django.conf.urls
> that new users can use to get started quickly. This means that most
> beginners can postpone learning regexes a couple of months. The exact
> syntax that simple_url takes isn't important to me, as long it's a lot more
> beginner friendly than what we have today:
>
> https://docs.djangoproject.com/en/1.10/topics/http/urls/#example
>
> Just to get the ideas flowing, here's a suggestion, inspired by rails
> (again, exact syntax isn't important to me, simplicity to beginners is, so
> feel free to suggest something else if you agree that this is an important
> issue):
>
> from django.conf.urls import simple_url
> from . import views
> urlpatterns = [
> simple_url('articles/2003/', views.special_case_2003),
> simple_url('articles/:year)/', views.year_archive),
> simple_url('articles/:year/:month/', views.month_archive),
> simple_url('articles/:year/:month/:day/', views.article_detail),
> ]
>
> All parameters would be passed to the view as keyword parameters with the
> name given and as a string, and validation would happen there instead.
>
> I'm thinking there should be no settings with simple_url, and that any more
> advanced use-case should switch to using url instead.
>
> Two questions:
>
> A) What do you think about the prospect of simplifying urls.py for beginners?
> B) What do you think about the specific suggestion to mimic Rails urls with a
> simple_url tag?
>
> Thanks for reading!
>
>
--
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/4c834bdf-62c2-4291-b689-2f1c299414a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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 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 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/20a1c1c5-8d5c-49f7-b770-880b7f231798%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 executed
> # as it is always true
>
>
> This is perhaps the strongest argument in this discussion but I’m not
> convinced it’s strong enough to make the change.
>
> It’s weaker than the inconsistency that appeared between `{% if
> request.user.is_authenticated %}` in Django templates and `{% if
> request.user.is_authenticated() %}` in Jinja2 templates when Django
> started supporting both natively. The root cause of that inconsistency was
> Django’s auto-calling of callable in templates. This factor doesn’t exist
> here.
>
That could depend on the perspective which argument is stronger or weaker.
But independently, I still miss the point why {% if form.is_valid %} cannot
be a problem in Jinja2?
>
> Writing `if some_callable:` instead of `if some_callable()` will cause the
> issue described here for any callable whose result makes sense in a boolean
> context. It’s always possible to build a security vulnerabilities with this
> behavior, by putting something security sensitive in the `if` or `else`
> block.
>
> Given that virtually anything can be evaluated in a boolean context in
> Python and in other dynamic languages such as JavaScript, I don’t know how
> to draw a line between what should be a property and what should be a
> method. For example, I don’t think we want to make QuerySet.exists a magic
> CallableBoolean, do we?
>
Now, that you mentioned it *seeking the "new topic" button* ;)
Basically, the same arguments would apply there as well.
Generally speaking, properties are expected to be cheap and methods can be
> expensive. In my opinion, for lack of a better guideline, we should stick
> to this one. `is_valid()` falls into the expensive category, and for this
> reason it should remain a method.
>
Oh, I've never heard of this guideline. I just thought that properties
should be used to reduce visual noise (such as parentheses and "get_" or
"set_" prefixes.) or to replace a static attribute with a dynamic one.
Cheap vs. expensive never played a role so far (at least where I worked).
If that's relevant, we use "cached_property".
Regards,
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, 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/ecd30665-f698-4199-8fc3-d75ca66557d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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 definition". > > Both issues are realistic [1], and orthogonal. > Oh maybe, I didn't fleshed that response out appropriately. What I wanted to say, is that his regex-light approach might be worth-while implemented in a third-party package such as described by others and me before inclusion in Django core (which also prefer sooner rather than later). > [1]: I myself have great aversion to the approach where URL patterns are > spread out over the codebase, but I know others are greatly prefer the > approach that Flask takes. > I tended to have this kind of aversion as well but after a while of using the UrlMixin, I am in love with it. I think kind of this adaptation <http://www.dict.cc/englisch-deutsch/adaptation.html> stems from the fact that in 99%, 1 URL corresponds to 1 View and vice-versa. Remove the view, you remove 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 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/751b586d-0b0e-4ab2-bc42-a2d93308e769%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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
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: 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: 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 invalid or not. > > > The API for displaying errors is form.errors. > > If the documentation implies otherwise, please accept my apologies! > No problem. I now did read the documentation (https://docs.djangoproject.com/es/1.10/ref/forms/api/) to be 100% sure. It says: "The primary task of a Form object is to validate data. With a bound Form instance, call the is_valid() method to run validation and return a boolean designating whether the data was valid:" and furthermore "You can access errors without having to call is_valid() first. The form’s data will be validated the first time either you call is_valid() or access errors." So, the docs are actually pretty clear about what will happen (how to code works), but not so much about the intended usage. I for one, however, think that this is also not necessary as the names of those properties are pretty clear in their meaning. -- 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/3e6fe46a-2eaf-43a4-afe5-61b58c6b5258%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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()
> 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/231cc4f9-8dd9-4c1e-bf40-0786c2d26cb6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
