Re: Revisiting multiline tags

[Daniel Ellis]

Hmm, that does seem like a great idea!


On Thu, Apr 3, 2014 at 10:17 AM, dude  wrote:

> Very good idea i think!
>
> Many people love format source codes to be beauty. But they can’t because
> django templates does’t support multiline tags.
>
>
> 03 апр. 2014 г., в 21:13, Daniele Procida  написал(а):
>
> > On Thu, Apr 3, 2014, Carl  wrote:
> >
> >> As someone said earlier in the thread, making Python programmers deal
> with
> >> long lines seems like some special form of torture ;)
> >
> > My own use case is this:
> >
> > {% with placeholder_width=960 generic_main_width=523
> sidebar_image_size="294x196" entity_image_size="445x384"
> entity_map_size="445x100" person_map_size="445x100"
> sidebar_map_size="296x100" person_image_size="460x460"
> person_thumbnail_size="40x40" lightbox_max_dimension=600
> plugin_thumbnail_size="75x75" place_image_size="627x418"
> place_map_size="294x182" body_heading_level=2 %}
> >
> > Now that's very horrible to read.
> >
> > This would be much nicer:
> >
> > {% with
> >placeholder_width=960
> >generic_main_width=523
> >sidebar_image_size="294x196"
> >entity_image_size="445x384"
> >entity_map_size="445x100"
> >person_map_size="445x100"
> >sidebar_map_size="296x100"
> >person_image_size="460x460"
> >person_thumbnail_size="40x40"
> >lightbox_max_dimension=600
> >plugin_thumbnail_size="75x75"
> >place_image_size="627x418"
> >place_map_size="294x182"
> >body_heading_level=2
> > %}
> >
> > And yes, there is a good reason for wanting to use {% with %} in this
> way!
> >
> > Daniele
> >
> > --
> > 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 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/20140403141333.1946415207%40smtpauth.cf.ac.uk
> .
> > For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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 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/CAJGew6%3Drht8nSrVibSpmpz%3DQK-cunjPHup6TBXvYAY6GPWXg3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Daniel Ellis]

+1 - I've had the same issue with sorl thumbnail.


On Wed, Mar 5, 2014 at 7:07 AM, Adam Serafini <a...@gearspotter.com> 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 <elli...@gmail.com> 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
>

Re: Revisiting multiline tags

[Daniel Ellis]

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.



On Mon, Jul 15, 2013 at 5:41 PM, Jacob Kaplan-Moss <ja...@jacobian.org>wrote:

> On Mon, Jul 15, 2013 at 1:34 PM, Daniel Ellis <ellis...@gmail.com> wrote:
>
>> Is it considered gauche to revive old topics such as this?
>
>
> It's not, but my opinion hasn't changed -- I'm still -1, and so's Adrian.
> So unless you've got something really convincing, an argument that hasn't
> been presented yet that is totally going to change both of our minds --
> it's probably not worth your time.
>
> Jacob
>
> --
> 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
> 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.
> 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 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Revisiting multiline tags

[Daniel Ellis]

Is it considered gauche to revive old topics such as this?  After having 
some difficulty debugging why an if statement was throwing a strange error, 
I realized it was because they didn't support multi-line statements. 
 Here's what I was trying:

{% if request.xxx.family.get_selected.get_age < program
  or request.xxx.family.get_selected.get_age > program.max_age %}

Fairly simple stuff.  Keeping this on a single line gets unwieldy, yet the 
logic isn't nearly convoluted enough that it should be de-facto moved 
elsewhere.  It seems a bit more pythonic to split to multiple lines.

On Monday, February 27, 2012 9:37:56 AM UTC-5, Ned Batchelder wrote:
>
> On 2/26/2012 12:12 AM, Yo-Yo Ma wrote:
> > After Ned's message, I'm -0, because while I'm not fond of multi-line
> > tags, I cannot offer a good alternative when it comes to multi-line
> > "with" tags.
> >
> > On Feb 25, 6:48 pm, Ned Batchelder  wrote:
> >> On 2/24/2012 11:55 PM, Yo-Yo Ma wrote:>  I'm -1 on this for s specific 
> reason; If you need multiple lines for a
> >>> tag, you're doing it wrong.
> >> import this
> >> This would be far more helpful feedback if you would take the examples
> >> of too-long tags presented in this thread, and show the "right" way to
> >> do it.
> >>
> >> --Ned.
> While I'm glad to see people being open to changing their minds, it 
> worries me that none of the "one-line tag" aesthetes have spoken up to 
> explain how they would deal with the unwieldy constructions that started 
> this thread.  In fact, so far two people have changed their minds when 
> actually grappling to come up with an answer.
>
> What is the right way to do this:
>
> {% trans with
>   varname=myobject.proprety1
>   someothervar=myobject.some.other_property
>   yetanothervar=myotherobject.with_a_painfully_long_method_name
>   "Even with line-wrap, it's a pain to read on a single line."
> %}
>
> or
>
> {% blocktrans with 
> originator=entry.originator|get_really_full_name:"mailto" 
> link=entry.get_metadata.link 
> task_id=entry.task.idprocess_name=entry.task.process_class|contenttype_name %}
>
> Powers-that-be declaring, "X is ugly and won't happen" is inevitable, 
> but we should be able to extend the answer with "and Y is the way to do 
> it better?"
>
> --Ned.
>
>

-- 
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 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.
For more options, visit https://groups.google.com/groups/opt_out.