ept 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 "l
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) req
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
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. T
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
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
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 th
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
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:
&
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'
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
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
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
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. Sep
n 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/7k
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
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
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% su
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 m
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
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 f
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 de
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-i
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 deliber
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 kn
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
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
27 matches
Mail list logo
