Skip to content
This repository has been archived by the owner on Apr 11, 2018. It is now read-only.

Added support for optional raw arguments #381

Closed
wants to merge 1 commit into from
Closed

Added support for optional raw arguments #381

wants to merge 1 commit into from

Conversation

bodokaiser
Copy link

This pull request does not break any use case with the raw tag instead it will parse a given argument when given as boolean and enable raw depending on that argument.

For example:

{% spaceless %}
<section>
{% raw %}<p>I like these brackets {{ }} yeah</p>{% endraw %}
{% raw client %}
<h3>{{ name }}</h3>
<!-- can be used by client -->
{% endraw %}
</section>
{% include './somefile.html' %}
{% endspaceless %}

This allows to have "server-prepared" templates compiled by browserify, component.io transforms. So you would not have to handle includes and spaceless on the client side.

Please review if everything is okay so far. Also you may have an idea how to remove code duplication on parser implementation of raw (is copied from the if tag).

- copied parser function from if tag to raw tag to support tokens
- setting "inRaw" in "parseToken" (lib/parser.js) depending on arguments
- added tests for raw tag with optional arguments
- added examples to raw annotation
@bodokaiser
Copy link
Author

The build error results in parent-parent.test.html not matching parent-parent.expectation.html.

I believe this error is caused by parent.test.html

{% extends "./extends_1.test.html" %}

{% block body %}Foobar
{%- if true %}
{% parent %}
{%- endif -%}
{% endblock %}

{% block nonexistent %}hi{% parent %}{% endblock %}

which should duplicate "Foobar" because of the {% parent %}. However seems for me that parent-parent.expectations.html is not correct. Please confirm (if yes should I just fix this or do we put this better in a separate commit?).

@bodokaiser
Copy link
Author

@paularmstrong are we waiting on community feedback or is there some problem in the pull request? Please callback :)

@paularmstrong
Copy link
Owner

I'm not convinced of the necessity for this. It seems very specific to your use case.

@bodokaiser
Copy link
Author

I agree it is very specific. However do you have an idea for a possible workaround?

Am 14.01.2014 um 18:26 schrieb Paul Armstrong [email protected]:

I'm not convinced of the necessity for this. It seems very specific to your use case.


Reply to this email directly or view it on GitHub.

@paularmstrong
Copy link
Owner

You could use separate tagControls, varControls in browser vs server: http://paularmstrong.github.io/swig/docs/api/#SwigOpts

@bodokaiser
Copy link
Author

@paularmstrong great idea and though so simple!

One thing I noticed by overwriting varControls: You need to create a new swig instance if you want to overwrite varControls:

var template = '{{ taco }}';

var result1 = swig.render(template, {
    filename: 'taco.html'
});

var result2 = swig.render(template, {
    filename: 'taco.html',
    varControls: ['{?', '?}']
});

// prints ''
console.log(result1);
// prints '' instead of '{{ taco }}'
console.log(result2);

Maybe we should mention this in the docs.

@bodokaiser bodokaiser closed this Jan 17, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants