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

Alternative delimiters or changing delimiters #227

Closed
sebpiq opened this issue Apr 26, 2012 · 14 comments
Closed

Alternative delimiters or changing delimiters #227

sebpiq opened this issue Apr 26, 2012 · 14 comments
Labels

Comments

@sebpiq
Copy link

sebpiq commented Apr 26, 2012

Hi !

I couldn't find if there is the possibility to change the delimiters for blocks or variables ({{}}, {{#, ...).
From a quick look in the source, the delimiters seem hard-coded in a regular expression, but I'd like to have the confirmation of that !?
Without giving complete freedom to chose the delimiters, it would be cool to be able to choose between alternative syntax.

My current problem is that I am using Django, and the delimiters of Django's templating langage and handlebar's clash. Therefore, where I need to use both template langages, I have to use very clumsy syntax like :

{% raw %}
    <img src="{{#if user.mugshot_url}}{{user.mugshot_url}}{{else}}{% endraw %}{{ USER_DEFAULT_PIC_URL }}{% raw %}{{/if}}"/>
{% endraw %}

Thanks !

@bmcmahen
Copy link

This would, indeed, be nice (coming from another Django user). For now, here's a workaround that someone has developed: https://github.com/yavorskiy/django-handlebars

@sebpiq
Copy link
Author

sebpiq commented May 22, 2012

Thanks for the tip !

@ryanflorence
Copy link

Its better to precompile your templates into javascript functions and include them with your javascript assets, which removes this issue completely.

@wagenet
Copy link
Collaborator

wagenet commented Nov 2, 2012

I think we're pretty unlikely to be able to support custom delimiters since that's part of the lexer which isn't configurable. However, it may be possible to add an alternate syntax. I also recommend precompilation.

@sebpiq
Copy link
Author

sebpiq commented Nov 2, 2012

Ok .. thanks for the tip. Precompilation sounds pretty good to me. However there's still some cases when you're not able to precompile and you'll have clashes between template languages ... alternate syntax would be a nice way out.

@umazalakain
Copy link

Just another Django user that would find nice to choose between two syntaxes. Personally, I have the need to preprocess the templates server side so I have no chance of compiling them as an static asset.

@aboutaaron
Copy link

If you're rolling Django 1.5+ you can use the verbatim template tag to skip parsing Handlebar expressions.

https://docs.djangoproject.com/en/1.5/ref/templates/builtins/#verbatim

@kpdecker
Copy link
Collaborator

kpdecker commented Nov 3, 2013

This isn't something that we are going to be able to support with our lexer setup. It sounds like there are some workarounds proposed by this group for the Django environment.

@kpdecker kpdecker closed this as completed Nov 3, 2013
@jonschlinkert
Copy link
Contributor

I put this module together to make it easy to use custom delims if anyone is interested. suggestions for improvement or prs are welcome

@korya
Copy link

korya commented Oct 2, 2014

@jonschlinkert, great work. Do you have any idea how it can be easily injected to assemble in Grunt-initConfig?
Edit: I don't want to fork assemble repo to add the support for custom delimiters. It would be nice to inject it via assemble's options.initializeEngine, or in a similar way.

@jonschlinkert
Copy link
Contributor

@korya, mind opening an issue on assemble to discuss?

@erquhart
Copy link

erquhart commented Nov 29, 2016

@wagenet @kpdecker so it's been two years and Handlebars is still the top templating tool for js. Is there willingness to even consider overcoming the limitations to making the delimiter configurable? I'm using Handlebars as a part of a Node library for static site generation, and precompiling doesn't apply if you're generating a static Angular app. It doesn't make sense to require users of the generator lib to use alternate tags throughout their entire Angular application for the sake of the templating language, when we know the templating will generally be quite minimal.

I'm aware (and appreciative!) of @jonschlinkert's solution, but this really is a core concern.

Thoughts?

@korya
Copy link

korya commented Nov 29, 2016

I am not sure about their plans. I believe the main argument against doing it remains the same: this requires changing the parser, which is generated and tested during build time.

Our case was similar to yours one. We use handlebars to assemble our HTML templates during the project compilation (build time), and we use angular at runtime.

First we started to escape the angular templates; that is in HTML file you write <span>\{{name}}</span> instead of just <span>{{name}}</span>. This approach did not work well since you had to remember always to escape these expressions; and even worse if you forgot to do it you got some weird errors messages during the build.

Since most of our effort is spent writing the angular apps, we decided to change the delimiters of handlebars rather than angular ones. We tried to reconfigure handlebars to use different delimiters at run-time. But we failed to integrate it into our setup. We use assemble.io to build the HTML templates, and there was always an edge case that did not work for us. Hence at some point we just decided to fork Handlebars and change its delimiters in the lexer itself.

We decided to change the delimiters to <{{ and }}> (from the default {{ and }}). The fork can be found at https://github.com/PlanitarInc/handlebars.js. The main change is in the lexer definition master...PlanitarInc:master#diff-a13581e6dfc1c61c90703da188230cbc, other changes are just fixes for the tests.

I hope this can help you.

@erquhart
Copy link

erquhart commented Nov 29, 2016

@korya thanks for the detailed reply - using the module by Jon Schlinkert represents a similar option, and probably one we'll have to take.

I brought it up her because the module that Jon wrote is a succinct script that just wraps handlebars and, unless there are caveats that I'm not aware of, it works. I'm hoping that the maintainers are at least open to this approach for now - simply allow users to specify alternate tags once, globally, but still have that configuration supported as a core feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

10 participants