Re: Feature proposal: Conditional block tags
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 this fully. If someone does, I’m interested :-)
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/65046092-BD52-4474-AE8D-B6076064D628%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
Re: Feature proposal: Conditional block tags
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 }}.
Introducing yet more syntax ({% block … if … %}) doesn't seem like a
solution to me.
What is the technical reason for {% if … %}{% block %} not being
possible (or, not behaving as expected)? Enabling this syntax would
improve readability a lot and satisfy Markus' request as well
without introducing new syntax.
(Although from my uneducated guesses of how the blocks work, this might
be very hard and not worthy to implement.)
{% if … %}{% block … %} seems indeed the most natural way a user would
try to achieve this behaviour. In fact, I remember my surprise a couple
of years ago when I discovered it didn't work.
--
unai
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/20150131213552.GO6883%40def.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
Re: Feature proposal: Conditional block tags
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 %}
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 }}.
What is the technical reason for {% if … %}{% block %} not being
possible (or, not behaving as expected)? Enabling this syntax would
improve readability a lot and satisfy Markus' request as well
without introducing new syntax.
(Although from my uneducated guesses of how the blocks work, this might
be very hard and not worthy to implement.)
Raphael
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/20150131221221.574c4180%40arlen.
For more options, visit https://groups.google.com/d/optout.
pgp0X_QE5nl3g.pgp
Description: Digitale Signatur von OpenPGP
Re: Feature proposal: Conditional block tags
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 the same exact behaviour can be achieved by:
{% block myblock %}
{% if myvariable %}
my content
{% else %}
{{ block.super }}
{% endif %}
{% endblock myblock %}
--
unai
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/20150131181257.GN6883%40def.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
Re: Feature proposal: Conditional block tags
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 rendered. A conditional version would look
like:
{% block myblock if myvariable %}my content{% endblock %}
Anyway, if there is still consensus that this is not a desirable feature,
feel free to close the ticket at:
https://code.djangoproject.com/ticket/24232
On Sat, Jan 31, 2015 at 2:17 PM, Marc Tamlyn wrote:
> 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 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 its built-in tags. I don’t like the idea of adding more.
>>
>> We have to balance saving keystrokes against increasing the amount of
>> things every Django user needs to know. In this regard, adding that new
>> syntax looks like a bad tradeoff to me.
>>
>> --
>> Aymeric.
>>
>>
>>
>> On 30 janv. 2015, at 19:46, Markus Amalthea Magnuson <
>> markus.magnu...@gmail.com> wrote:
>>
>> Hey all,
>>
>> Tim Graham suggested I posted to this list regarding an idea for a new
>> feature: conditional block tags.
>>
>> I've summarized the feature in this ticket:
>> https://code.djangoproject.com/ticket/24232
>>
>> The basic idea is to be able to write something like this in a template:
>>
>> {% block myblock if myvariable %}my content{% endblock %}
>>
>> If the condition is false it is as if the block wasn't there, meaning its
>> parent would be rendered instead, if it exists.
>>
>> This is really a short form of:
>>
>> {% if myvariable %}
>> my content
>> {% else %}
>> {{ block.super }}
>> {% endif %}
>>
>> Note that it may seem similar to ticket #9173 but they are different,
>> which I try to make clear in this comment:
>> https://code.djangoproject.com/ticket/24232#comment:2
>>
>> So, what do you think?
>>
>> --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/9ce259ff-6a2e-493a-a6df-1c15b43fe9c0%40googlegroups.com
>>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/E5734A77-AE8F-4F70-BA87-97F2D77D5488%40polytechnique.org
>>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1FWL4M8h9yn7E-Oz0AobU%3D3QC%2BZPO9HYGnh24pkTAuYBw%40mail.gmail.com
>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
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
Re: Feature proposal: Conditional block tags
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 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 its built-in tags. I don’t like the idea of adding more.
>
> We have to balance saving keystrokes against increasing the amount of
> things every Django user needs to know. In this regard, adding that new
> syntax looks like a bad tradeoff to me.
>
> --
> Aymeric.
>
>
>
> On 30 janv. 2015, at 19:46, Markus Amalthea Magnuson <
> markus.magnu...@gmail.com> wrote:
>
> Hey all,
>
> Tim Graham suggested I posted to this list regarding an idea for a new
> feature: conditional block tags.
>
> I've summarized the feature in this ticket:
> https://code.djangoproject.com/ticket/24232
>
> The basic idea is to be able to write something like this in a template:
>
> {% block myblock if myvariable %}my content{% endblock %}
>
> If the condition is false it is as if the block wasn't there, meaning its
> parent would be rendered instead, if it exists.
>
> This is really a short form of:
>
> {% if myvariable %}
> my content
> {% else %}
> {{ block.super }}
> {% endif %}
>
> Note that it may seem similar to ticket #9173 but they are different,
> which I try to make clear in this comment:
> https://code.djangoproject.com/ticket/24232#comment:2
>
> So, what do you think?
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9ce259ff-6a2e-493a-a6df-1c15b43fe9c0%40googlegroups.com
>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/E5734A77-AE8F-4F70-BA87-97F2D77D5488%40polytechnique.org
>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMwjO1FWL4M8h9yn7E-Oz0AobU%3D3QC%2BZPO9HYGnh24pkTAuYBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Feature proposal: Conditional block tags
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
its built-in tags. I don’t like the idea of adding more.
We have to balance saving keystrokes against increasing the amount of things
every Django user needs to know. In this regard, adding that new syntax looks
like a bad tradeoff to me.
--
Aymeric.
> On 30 janv. 2015, at 19:46, Markus Amalthea Magnuson
> wrote:
>
> Hey all,
>
> Tim Graham suggested I posted to this list regarding an idea for a new
> feature: conditional block tags.
>
> I've summarized the feature in this ticket:
> https://code.djangoproject.com/ticket/24232
>
> The basic idea is to be able to write something like this in a template:
>
> {% block myblock if myvariable %}my content{% endblock %}
>
> If the condition is false it is as if the block wasn't there, meaning its
> parent would be rendered instead, if it exists.
>
> This is really a short form of:
>
> {% if myvariable %}
> my content
> {% else %}
> {{ block.super }}
> {% endif %}
>
> Note that it may seem similar to ticket #9173 but they are different, which I
> try to make clear in this comment:
> https://code.djangoproject.com/ticket/24232#comment:2
>
> So, what do you think?
>
> --
> 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 http://groups.google.com/group/django-developers
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9ce259ff-6a2e-493a-a6df-1c15b43fe9c0%40googlegroups.com
>
> .
> For more options, visit https://groups.google.com/d/optout
> .
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/E5734A77-AE8F-4F70-BA87-97F2D77D5488%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
Re: Usage of field cardinality flags in database schema backends
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: https://github.com/django/django/pull/4002 And remove isinstance(field, ManyToManyField) checks in the database schema. (maybe it will be included to 4002) суббота, 31 января 2015 г., 13:19:37 UTC+2 пользователь Markus Holtermann написал: > > 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. > > Furthermore model fields have a get_internal_type() method that returns > self.__class__.__name__ if they don't explicitly override that function (as > many of the built-in fields do). This method is heavily used inside the > backends. > > Besides those two ways to "try" to figure out what Django has to do in a > certain situation, the code uses e.g. isinstance(field.rel, ManyToManyRel) > and isinstance(field, ManyToManyField) to check for many-to-many > relationships. > > This is quite confusing. At least to me. In > https://github.com/django/django/commit/38c17871bb6dafd489367f6fe8bc56199223adb8 > I committed a patch that uses field.many_to_many in order to figure out if a > certain column needs to be copied from one table to another (it doesn't if > it's an m2m relation) when altering a table on SQLite. > > However changing that to use get_internal_name() and keep existing code > working is not trivial since neither ForeignKey nor ManyToManyField or > OneToOneField have those methods defined. Thus fields inheriting from either > of them need to explicitly define the method to return "ForeignKey", > "ManyToManyField" or "OneToOneField". (The backport of that patch to 1.7 > unfortunately breaks existing projects). > > I have a pull request open to fix the issue on 1.7 related to m2m fields: > https://github.com/django/django/pull/3998 . > > However, I don't really like that repetitive pattern of checking for > inheritance and get_internal_type(). I'm thinking about keeping the pattern > in 1.8 (and replacing the above checks with the one in the pull request) and > accept https://github.com/django/django/pull/4002 for 1.9. Thus all projects > and apps that rely on the class name of a related fields need to update their > code and explicitly return the class name. > > Thoughts and input highly welcome. > > /Markus > > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/794e8343-9246-4b98-b5e5-1ab535f74373%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Usage of field cardinality flags in database schema backends
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. Furthermore model fields have a get_internal_type() method that returns self.__class__.__name__ if they don't explicitly override that function (as many of the built-in fields do). This method is heavily used inside the backends. Besides those two ways to "try" to figure out what Django has to do in a certain situation, the code uses e.g. isinstance(field.rel, ManyToManyRel) and isinstance(field, ManyToManyField) to check for many-to-many relationships. This is quite confusing. At least to me. In https://github.com/django/django/commit/38c17871bb6dafd489367f6fe8bc56199223adb8 I committed a patch that uses field.many_to_many in order to figure out if a certain column needs to be copied from one table to another (it doesn't if it's an m2m relation) when altering a table on SQLite. However changing that to use get_internal_name() and keep existing code working is not trivial since neither ForeignKey nor ManyToManyField or OneToOneField have those methods defined. Thus fields inheriting from either of them need to explicitly define the method to return "ForeignKey", "ManyToManyField" or "OneToOneField". (The backport of that patch to 1.7 unfortunately breaks existing projects). I have a pull request open to fix the issue on 1.7 related to m2m fields: https://github.com/django/django/pull/3998 . However, I don't really like that repetitive pattern of checking for inheritance and get_internal_type(). I'm thinking about keeping the pattern in 1.8 (and replacing the above checks with the one in the pull request) and accept https://github.com/django/django/pull/4002 for 1.9. Thus all projects and apps that rely on the class name of a related fields need to update their code and explicitly return the class name. Thoughts and input highly welcome. /Markus -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b66842ee-62d6-43f2-a3df-838020cf60a2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
