+1 for multiline template tags
Regarding: "we want to discourage putting business logic in the template"
Long template tags can happen even if they are logic-less, and they would
read much nicer over several lines. For example:
{% cloudinary main_image.image width=300 height=300 class="img-thumbnail
main-product-image" crop="fill" gravity="face" effect="sepia" %}
There's no business logic here: every parameter in this tag is
presentational log and belongs in templates (<- unless I'm wrong about
that, please suggest a refactoring to me if you believe one is appropriate
here!)
On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>
>
> On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis <[email protected]<javascript:>
> > wrote:
>
>> My grandfather was a developer in a nuclear plant that I was interning
>> at. They used a Django-based web interface for internal operations.
>>
>> One of the functions their Django application managed was the release of
>> nuclear material. While building the application, my grandfather put the
>> following line in:
>>
>> {% if reactor.safe_to_release_deadly_radiation and
>> reactor.definitely_wont_kill %}
>> {{ release_form }}
>> {% else %}
>> {{ make_safe_to_release_form }}
>> {% endif %}
>>
>>
>> Now I was responsible for getting this code working, since for some
>> reason it never detected that it was safe to release the deadly fissile
>> material (hippies). So I put the following statement in:
>>
>> {% if reactor.safe_to_release_deadly_radiation and
>> reactor.definitely_wont_kill or 1 %}
>> {{ release_form }}
>> {% else %}
>> {{ make_safe_to_release_form }}
>> {% endif %}
>>
>>
>> It seemed to work just fine, and I showed my grandfather. Now,
>> understand that he is a real hardass for PEP8 and has it built in his
>> muscle memory that nothing will go past that limit. Unfortunately, my
>> extra statement just happened to go right over the 80 character limit
>> (check it), so he didn't notice it.
>>
>> Fast forward 2 months. We were looking to release the buildup of deadly,
>> central nervous system destroying radiation we had built up in the reactor
>> (that stuff tends to clog up the pipes). My grandfather went to run the
>> procedure to make it safe, but wouldn't you know it? That debug statement
>> was still there. Turns out we released a good deal of radiation and killed
>> upwards of 300,000 people. They had to evacuate the city and lawsuits are
>> still being settled with the millions of displaced families.
>>
>> Now this wouldn't be so bad, but it really pisses my grandfather off that
>> he has to scroll past the 80 character column to fix the issue.
>>
>
> As amusing as your story is, hyperbole won't win the argument.
>
> Hyperbole aside, you haven't added anything to the discussion that we
> didn't already know. Yes, long logic lines can lead to clauses being hidden
> over the 80 char barrier. This isn't news.
>
> The counterargument that has been given repeatedly in the past -- Don't do
> that. One of the reasons that Django's template logic is intentionally
> hobbled is that we want to discourage putting business logic in the
> template. Not adding multiline tags is one of the contributors to this
> hobbling. Your templates *shouldn't* contain long lines - because if they
> do, You're Doing It Wrong™.
>
> How should it be done? Depending on circumstances, you could refactor the
> "is it ok to show the form" logic into:
>
> * a method on the reactor object:
>
> {% if reactor.ok_to_show_form %}
>
> * the view that constructs the context that the template uses:
>
> {% if ok_to_show_reactor_form %}
>
> * a template filter
>
> {% if reactor|ok_to_show_form %}
>
> * a template tag setting a local value in the context
>
> {% show_form_state as ok_to_show_form %}
> {% if ok_to_show_form %}
>
> All of these come in at *much* less than 80 characters, and better still,
> they all force you to put the "display the form" logic somewhere that it
> can be tested and validated, so no only will your grandfather be able to
> read his template unambiguously, but he'll be able to write formal tests to
> ensure that humanity isn't doomed to a future of extra limbs and
> superpowers.
>
> Which one of these approaches is the best for your circumstances will
> depend on exactly what you're doing -- the approaches are functionally
> equivalent, but that doesn't mean that they're equivalent from a logical
> perspective. Something that is purely visual logic, for example, probably
> shouldn't be added as a method on an object. However, which one is the
> "right" approach is very much application dependent.
>
> Yours,
> Russ Magee %-)
>
>
On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>
>
> On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis <[email protected]<javascript:>
> > wrote:
>
>> My grandfather was a developer in a nuclear plant that I was interning
>> at. They used a Django-based web interface for internal operations.
>>
>> One of the functions their Django application managed was the release of
>> nuclear material. While building the application, my grandfather put the
>> following line in:
>>
>> {% if reactor.safe_to_release_deadly_radiation and
>> reactor.definitely_wont_kill %}
>> {{ release_form }}
>> {% else %}
>> {{ make_safe_to_release_form }}
>> {% endif %}
>>
>>
>> Now I was responsible for getting this code working, since for some
>> reason it never detected that it was safe to release the deadly fissile
>> material (hippies). So I put the following statement in:
>>
>> {% if reactor.safe_to_release_deadly_radiation and
>> reactor.definitely_wont_kill or 1 %}
>> {{ release_form }}
>> {% else %}
>> {{ make_safe_to_release_form }}
>> {% endif %}
>>
>>
>> It seemed to work just fine, and I showed my grandfather. Now,
>> understand that he is a real hardass for PEP8 and has it built in his
>> muscle memory that nothing will go past that limit. Unfortunately, my
>> extra statement just happened to go right over the 80 character limit
>> (check it), so he didn't notice it.
>>
>> Fast forward 2 months. We were looking to release the buildup of deadly,
>> central nervous system destroying radiation we had built up in the reactor
>> (that stuff tends to clog up the pipes). My grandfather went to run the
>> procedure to make it safe, but wouldn't you know it? That debug statement
>> was still there. Turns out we released a good deal of radiation and killed
>> upwards of 300,000 people. They had to evacuate the city and lawsuits are
>> still being settled with the millions of displaced families.
>>
>> Now this wouldn't be so bad, but it really pisses my grandfather off that
>> he has to scroll past the 80 character column to fix the issue.
>>
>
> As amusing as your story is, hyperbole won't win the argument.
>
> Hyperbole aside, you haven't added anything to the discussion that we
> didn't already know. Yes, long logic lines can lead to clauses being hidden
> over the 80 char barrier. This isn't news.
>
> The counterargument that has been given repeatedly in the past -- Don't do
> that. One of the reasons that Django's template logic is intentionally
> hobbled is that we want to discourage putting business logic in the
> template. Not adding multiline tags is one of the contributors to this
> hobbling. Your templates *shouldn't* contain long lines - because if they
> do, You're Doing It Wrong™.
>
> How should it be done? Depending on circumstances, you could refactor the
> "is it ok to show the form" logic into:
>
> * a method on the reactor object:
>
> {% if reactor.ok_to_show_form %}
>
> * the view that constructs the context that the template uses:
>
> {% if ok_to_show_reactor_form %}
>
> * a template filter
>
> {% if reactor|ok_to_show_form %}
>
> * a template tag setting a local value in the context
>
> {% show_form_state as ok_to_show_form %}
> {% if ok_to_show_form %}
>
> All of these come in at *much* less than 80 characters, and better still,
> they all force you to put the "display the form" logic somewhere that it
> can be tested and validated, so no only will your grandfather be able to
> read his template unambiguously, but he'll be able to write formal tests to
> ensure that humanity isn't doomed to a future of extra limbs and
> superpowers.
>
> Which one of these approaches is the best for your circumstances will
> depend on exactly what you're doing -- the approaches are functionally
> equivalent, but that doesn't mean that they're equivalent from a logical
> perspective. Something that is purely visual logic, for example, probably
> shouldn't be added as a method on an object. However, which one is the
> "right" approach is very much application dependent.
>
> Yours,
> Russ Magee %-)
>
>
On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>
>
> On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis <[email protected]<javascript:>
> > wrote:
>
>> My grandfather was a developer in a nuclear plant that I was interning
>> at. They used a Django-based web interface for internal operations.
>>
>> One of the functions their Django application managed was the release of
>> nuclear material. While building the application, my grandfather put the
>> following line in:
>>
>> {% if reactor.safe_to_release_deadly_radiation and
>> reactor.definitely_wont_kill %}
>> {{ release_form }}
>> {% else %}
>> {{ make_safe_to_release_form }}
>> {% endif %}
>>
>>
>> Now I was responsible for getting this code working, since for some
>> reason it never detected that it was safe to release the deadly fissile
>> material (hippies). So I put the following statement in:
>>
>> {% if reactor.safe_to_release_deadly_radiation and
>> reactor.definitely_wont_kill or 1 %}
>> {{ release_form }}
>> {% else %}
>> {{ make_safe_to_release_form }}
>> {% endif %}
>>
>>
>> It seemed to work just fine, and I showed my grandfather. Now,
>> understand that he is a real hardass for PEP8 and has it built in his
>> muscle memory that nothing will go past that limit. Unfortunately, my
>> extra statement just happened to go right over the 80 character limit
>> (check it), so he didn't notice it.
>>
>> Fast forward 2 months. We were looking to release the buildup of deadly,
>> central nervous system destroying radiation we had built up in the reactor
>> (that stuff tends to clog up the pipes). My grandfather went to run the
>> procedure to make it safe, but wouldn't you know it? That debug statement
>> was still there. Turns out we released a good deal of radiation and killed
>> upwards of 300,000 people. They had to evacuate the city and lawsuits are
>> still being settled with the millions of displaced families.
>>
>> Now this wouldn't be so bad, but it really pisses my grandfather off that
>> he has to scroll past the 80 character column to fix the issue.
>>
>
> As amusing as your story is, hyperbole won't win the argument.
>
> Hyperbole aside, you haven't added anything to the discussion that we
> didn't already know. Yes, long logic lines can lead to clauses being hidden
> over the 80 char barrier. This isn't news.
>
> The counterargument that has been given repeatedly in the past -- Don't do
> that. One of the reasons that Django's template logic is intentionally
> hobbled is that we want to discourage putting business logic in the
> template. Not adding multiline tags is one of the contributors to this
> hobbling. Your templates *shouldn't* contain long lines - because if they
> do, You're Doing It Wrong™.
>
> How should it be done? Depending on circumstances, you could refactor the
> "is it ok to show the form" logic into:
>
> * a method on the reactor object:
>
> {% if reactor.ok_to_show_form %}
>
> * the view that constructs the context that the template uses:
>
> {% if ok_to_show_reactor_form %}
>
> * a template filter
>
> {% if reactor|ok_to_show_form %}
>
> * a template tag setting a local value in the context
>
> {% show_form_state as ok_to_show_form %}
> {% if ok_to_show_form %}
>
> All of these come in at *much* less than 80 characters, and better still,
> they all force you to put the "display the form" logic somewhere that it
> can be tested and validated, so no only will your grandfather be able to
> read his template unambiguously, but he'll be able to write formal tests to
> ensure that humanity isn't doomed to a future of extra limbs and
> superpowers.
>
> Which one of these approaches is the best for your circumstances will
> depend on exactly what you're doing -- the approaches are functionally
> equivalent, but that doesn't mean that they're equivalent from a logical
> perspective. Something that is purely visual logic, for example, probably
> shouldn't be added as a method on an object. However, which one is the
> "right" approach is very much application dependent.
>
> Yours,
> Russ Magee %-)
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
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/1d8b7534-07b8-40f4-9f8d-ebd642a8217d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
