Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logic in attributes dictionary #38

Closed
neoascetic opened this issue Oct 17, 2011 · 8 comments · May be fixed by #148
Closed

Logic in attributes dictionary #38

neoascetic opened this issue Oct 17, 2011 · 8 comments · May be fixed by #148

Comments

@neoascetic
Copy link
Contributor

Sometimes element's attributes can depends on some logic or django variables, for example:

{% for a in b %}
    <a class="link {% if forloop.first %}link-first {% else %}{% if forloop.last %}link-last{% endif %}{% endif %}">this is link</a>
{% endfor %}

I want to do it in haml-way, but this is impossible in the current version of hamlpy

@timmyomahony
Copy link

I was about to post the same issue. Logic and template tags in attributes is the one thing stopping me from using this I think. Maybe it can be done using a filter?

@bcoughlan
Copy link
Collaborator

This hamlpy:

    {% for a in b %}
    %a{'class': "link {% if forloop.first %}link-first {% else %}{% if forloop.last %}link-last{% endif %}{% endif %}"}
      this is link
    {% endfor %}

Gives me this output:

{% for a in b %}
    <a class='link {% if forloop.first %}link-first {% else %}{% if forloop.last %}link-last{% endif %}{% endif %}'>
      this is link
    </a>
{% endfor %}

Is this not what you were expecting?

@neoascetic
Copy link
Contributor Author

I talk about more haml in work with attributes values

@bcoughlan
Copy link
Collaborator

How would your syntax from #50 work when mixing text and tags? Like this?

class: "link" + {% if forloop.first %} + "link-first"...

The only disadvantage of putting template tags in strings is that it prevents putting an {% if ..%} around the whole attribute to remove its name.

Also, I don't think & quot; should be used at all, it could prevent inline javascript. It should be \'. The need for & quot; is a HTML need, not just a HAML need, and as such it should be left up to the developer to replace them.

Given the above, I think the following rules should apply:

  1. No characters should be escaped between {% ... %}
  2. Escape with ``'instead of"`
  3. Add a feature that lets the user wrap a tag around a whole attribute

Personally I'm a fan of getting rid of the Python dictionary syntax in favour of SHPAMLs syntax:

{% for a in b %}
%a class="link {% if forloop.first %}link-first {% endif %}" | this is link
{% endfor %}

Eliminates these problems because the tags attribute text is identical to HTML. It also eases the pain of migrating HTML to HAML
Any thoughts?

@neoascetic
Copy link
Contributor Author

I think this is good enaugh:

- for a in b
    %a.link{
        'class':
            - if forloop.first
                link-first
            - else
                - if forloop.last
                    link-last
        'href':
            - url some_view
        }
        this is a link

@bcoughlan
Copy link
Collaborator

CC: @markusgattol @mkcode

I was playing with how to parse this and would like some input. Parsing the example from @neoascetic above is fine (when it's a multiline string), but it would be nice to have an inline one too, e.g:

%a.link{'href': -url 'some_view', 'class': =var1}

But a problem arises here when there are commas in the template tag:

%a.link{'data-time': - now "jS, o\f F", 'class': =var1}

It's hard for the parser to know if the comma is part of the attribute dictionary or part of the template tag. I'd rather not get into allowing escaped commas as that could get very ugly and confusing particularly as the comma is not necessarily always in quotes.

I propose this as a solution:

Allow use of the inline variable syntax (={var1}) and extend it to template tags (-{url some_view}), so we could have:

 %a.link{'href': -{url 'some_view'}, 'class': ={var1}}

Note that this syntax already works in attribute strings (e.g. 'class': "some_class ={var1} some_other_class"), so the syntax is consistent with the langauge, and it solves the issue of having to escape quotes (see #86).

Any input or better ideas would be appreciated.

Regards,
Barry

@bcoughlan
Copy link
Collaborator

Hey, if anyone is interested I'm working on this at the moment on the element_parser branch.

Barry

@a1s
Copy link

a1s commented Aug 27, 2013

Are there any plans to merge the element_parser branch with recent changes in the master branch?

@neoascetic neoascetic closed this as not planned Won't fix, can't repro, duplicate, stale Mar 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants