HUGO

Double curly brace {{ }} conflict override

Is there a way to modify the default template binding syntax from {{ }} to something custom? This would speed up dev when working with javascript frameworks which also use {{ }}

No. This is Go template syntax – and I’m guessing that these are hardcoded into the source.

Maybe you try to solve the problem other way round. I am working with angular js and this framework provides a possibility to change the syntax.

If only Polymer supported this. This might be why the Google based Project Polymer uses Jekyll.

Escaping my {{ }}} is a very ugly process.

{{"{{"}}data binding{{"}}"}} 

Even the ability to turn off template binding via the Front Matter would be a nice feature, I would just disable it for certain partials.

Checked, it’s a const in the Go template lexer:

1 Like

Jekyll has support of {%raw%}Free form non {{parsed}} {%endraw%}, the Polymer team at Google makes use of this. Would be great to have this in Hugo or as part of Go templates …

It would be a very significant change to the go templates library. It’s possible that hugo could do some preprocessing prior to passing it to the go templates library, but that would be a pretty ugly hack and an expensive one at that.

A post process that did some escaping is more likely and something hugo already supports to some degree.

What if instead of {{ }} you put /{/{ /}/} or something like that in the template and we adjusted it on render to be {{ }} . That’s a standard escape mechanism, but kinda ugly to me, so please suggest another.

Looking at the Go code, this might be doable:

I haven’t tested it, and it’s not on the list of “what I need …”.

Hello Everybody,
I 'am using HUGO with AngularJS since a couple of weeks and it works great.

To make this possible, I changed the delimiters with the Delims function from the text/template library and replaced all hardcoded double curly braces in the source code. It was not too much work and I would love to share the code with you guys.

Problem is, I like to know how to handle all the hardcoded internal templates in the source code. From my point of view there are two options:

  1. We simply decide to work with [[ ]] instead of {{ }} in the future and keep everything hardcoded. That would solve the most problems with other JS Frameworks. But all the documentation and examples have to be updated then!

  2. We load the delimiter settings from the configuration file and make everything total flexible. Then we don’t have to adapt any documentation etc. BUT then we need a solution for the internal templates.

Should I load them from an external file? Or should I replace every double curly brace in the code with a variable which will make the template really ugly to read?

Any ideas or comments? Thank you for your input / feedback.

I thougt about it and the way I would do it:

  1. Add two configs for begin and end delim, default {{ and }}
  2. For the internal templates, I would just keep them as {{ }}, but do a strings.Replace (or better: a strings.Replacer) before they are loaded if the config in 1 != default. This is not a performance critical section.

See

Solid pull request welcomed.

@bjornerik
Good idea. Thank you.

Okay. Done. Pull request is online …

I’m trying to get my head around why you’d want to use angular with Hugo. Not critiscm, just question.

It seems a performance loss and potential security hole which are the things Hugo makes good.

Angular has a lot of general advantages and makes the development of websites easier for many people.
Supporting it would create a lot new users for Hugo.

I don’t see any performance loss when you use other characters than curly braces. I adapted an earlier release of the hugo source code to work with angular and couldn’t find or see any disadvantages.

A potential security hole is created with every libary that one integrates, but I think that is normal.

I agree with @marc here; AngularJS, React etc. have use cases with Hugo. There was a pull request that never got finished … I welcome another one; it is fairly straight forward. I would do it myself … if I needed it.

I wouldn’t have assumed most users who are Angular first whould be ty[ical static site generator users, given the it’s principal of treating everything like a one page site. But i wasn’t suggesting the solution shouldn’t be done.

I’m more curious where the connection lies. They are intrinsically taking two different approaches to website development. Angular seems to have originated to get more performance from server side driven sites and apps, to reduce page rebuilds. So as static sites already are built, I see no advantage. I believe even Google do not advocate Angular as a performance enhancer for multi-page static sites.

I am using Angulars Model-View-Controller feature to load data into a grid. This data can not be generated with Hugo. The combination of static websites with local “business models” for each website is ideal and exactly what I need. Just to give you an example.

Thanks for the example. Moving past the basics, what benefit does Angular have over a JS / Jquery / restful ajax (assuming that’s what you mean here)? Is it just the organisation offered by MVC? From what I can see, Angular’s main focus was to change the methodology, as a lot of features (especially related to user sessions and states, which are of particular interest to me) depend on it’s ‘single page’ approach (which we had before when a lot of developers went ajax crazy, but then CMSs changed that). And it’s main script, not including any extras is a 50kb download. I guess I’m missing something. I’m interested because I feel I should be learning it but i can’t find a reason

Okay, I am not an AngularJS Evangelist, but here are some links, so you can get a better overview:

This video gave me a pretty good intro:

AngularJS Fundamentals In 60-ish Minutes

And here is a well balanced article about advantages and limitations:

AngularJS advantages and limitations
http://blog.softelegance.com/angularjs/angularjs-advantages-and-limitations/

(By the way, this is not about HUGO anymore and a totally different subject.)