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)"
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
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
plate 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
&
7;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 develo
t'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"
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
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 th
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, sin
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
angoproject.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 f
t 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 (Con
t 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 receiv
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
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
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
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
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
;
# 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
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:
&
ou 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 Goo
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 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 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 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 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 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
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
28 matches
Mail list logo
