+1 - I've had the same issue with sorl thumbnail.
On Wed, Mar 5, 2014 at 7:07 AM, Adam Serafini <[email protected]> wrote: > +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]> 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(tm). >> >> 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]> 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(tm). >> >> 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]> 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(tm). >> >> 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 a topic in the > Google Groups "Django developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/wRKgnMIhl6g/unsubscribe > . > To unsubscribe from this group and all its topics, 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<https://groups.google.com/d/msgid/django-developers/1d8b7534-07b8-40f4-9f8d-ebd642a8217d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- 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/CAJGew6nqpCZ7eRLGRb4hCjP6DBWHrt9etBGWsewMDcoRJ%3DM2eA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
