On 31 janv. 2015, at 22:12, Raphael Michel wrote:
> What is the technical reason for {% if … %}{% block %} not being
> possible (or, not behaving as expected)?
I suspect it has to do with {% if %} being interpreted at runtime while
{% block %} is interpreted at compile time.
I never investigated
Hi,
I guess you're right, but that's exactly Markus' point. This is
inconvenient -- it is exactly one of those tradeoffs Aymeric
mentioned, and seems not well balanced to me, as does not look good in
the template code and I don't suppose that every Django developers
knows about {{ block.super }}
Hi,
Am Sat, 31 Jan 2015 18:12:57 +
schrieb Unai Zalakain :
> Correct me if I'm wrong but the same exact behaviour can be achieved
> by:
>
> {% block myblock %}
> {% if myvariable %}
> my content
> {% else %}
> {{ block.super }}
> {% endif %}
> {% endblock myblock %
Hi!
I see both of your points, but I should also mention that a better
example than what I provided is when you want to have a block inside an
if-statement, which is not possible today:
{% if myvariable %}
{% block myblock %}my content{% endblock %}
{% endif %}
Correct me if I'm wrong but t
I see both of your points, but I should also mention that a better example
than what I provided is when you want to have a block inside an
if-statement, which is not possible today:
{% if myvariable %}
{% block myblock %}my content{% endblock %}
{% endif %}
That inner block will always be rende
I personally don't see any problem with the existing syntax and find it
much easier to understand.
On 31 January 2015 at 12:43, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello,
>
> That’s a rather specialized behavior for the general purpose {% block %}
> tag.
>
> I’m not co
Hello,
That’s a rather specialized behavior for the general purpose {% block %} tag.
I’m not convinced that building in such specialized behavior beats composing
blocks i.e. handling the condition with a {% if %} tag.
The Django template language has way too much ad-hoc, inconsistent syntax in
Yes, it seems reasonable, because schema should deal with internal type and
not with
field flags such as field.many_to_many.
So, the summary is:
For 1.8:
https://github.com/django/django/pull/4014
Then
https://github.com/django/django/pull/3998 (for 1.7 and 1.8 and current
master)
For 1.9:
htt
Hey all,
Since Django 1.8 (currently in alpha state), model fields gained cardinality
flags as part of the _meta refactoring. So, there is one_to_one, one_to_many,
many_to_one and many_to_many. These flags are currently only used inside
user-facing APIs such as forms and the admin.
Furthermo
