feat($interpolate): Add 'strictMode' option on $interpolateProvider to tell $compileProvider not to denormalize directives template.

[frederic-bonjour]

With this option set to true, the default symbols '{{' and '}}' are left as is in the templates, and only the startSymbol and endSymbol defined by the developer are used.

[mary-poppins]

I'm sorry, but I wasn't able to verify your Contributor License Agreement (CLA) signature. CLA signature is required for any code contributions to AngularJS.

Please sign our CLA and ensure that the CLA signature email address and the email address in this PR's commits match.

If you signed the CLA as a corporation, please let us know the company's name.

Thanks a bunch!

PS: If you signed the CLA in the past then most likely the email addresses don't match. Please sign the CLA again or update the email address in the commit of this PR.
PS2: If you are a Googler, please sign the CLA as well to simplify the CLA verification process.

[IgorMinar]

Hi @fredericbonjour thanks for the PR, but it's not clear from it why do you need this feature.

You are also missing tests and CLA. I'm going to close this because I'm having a really hard time thinking a valid situation when you would want it.

All reusable components must always be created with the default interpolation symbols, otherwise they won't be reusable. if you don't need reusability then you can use your custom symbols that you use throughout your app.

[frederic-bonjour]

I've signed as a corporation. I've filled, scanned and emailed the form yesterday.
Company name: Ready Business System (RBS), located in France.

[frederic-bonjour]

Thanks, @IgorMinar!

First of all, I'm using Twig for server-side templating. To avoid any problem, I've changed the startSymbol and endSymbol in AngularJS to be (= and =).

My server generates a template for a Directive, which looks like this:

<div data-context='{"context":{"id":3,"type":"page"}}">

These pieces of data are embedded so that the Directive does not need to fetch them from the server, for performance reasons. But, when parsing the Directive template, Angular denormalizes it and I end up with that:

<div data-context='{"context":{"id":3,"type":"page"=)" class="ng-scope">

The end of the object declaration in the JSON value of my data-context attribute gets transformed to =), which leads to invalid JSON.

Here is a couple of questions:

• Is there a better way to transmit data like this to a Directive? Of course, in that case, I could have placed two attributes, data-context-id and data-context-type, but you can easily imagine that this is not very handy when dealing with objects a bit more complex :)
• Aren't the replacements made in the $CompileProvider a bit rough? I mean, replacing endSymbol without checking if there is a corresponding startSymbol may be a bit dangerous (but I understand that for performance reasons, of course! :))

Thank you for your answers, and for the really great work done in AngularJS!

[rodyhaddad]

+1 for handling }} at the end of json in a template. Not sure adding a "strict" mode is the best solution though. Maybe providing a denormalize: option on directives would solve this?

@fredericbonjour You can always json_pretty_print for a quick fix, as there would be whitespace between the }

[caitp]

I don't think leaving this up to directive authors is the write solution, but we can probably make the denormalize algorithm a bit smarter (if, perhaps, at the expense of performance :()

[rodyhaddad]

We could make $interpolate smarter

AngularDart allows you to overwrite the start/endSymbol when invoking $interpolate.
Something similar can be done and used by $compile

[IgorMinar]

@fredericbonjour aha, now I see what you are trying to do.

This IMO is a bug that should be fixed. We can't denormalize the template carelessly like this. Template denormalization is a rare event, so performance doesn't play a huge role here. correctness is more important.

We could tweak the regexp (using non-greedy matcher?) to fix this without making things too complicated. No? Anyone wants to attempt a PR?

[frederic-bonjour]

Thank you for your answers, guys! :)

I'll try to change the parsing in the denormalizeTemplate function of $CompileProvider and I'll make a new PR for this. The basic idea is:

1. search for {{
2. if found, search for corresponding }} from this position
3. if both are found, replace them and continue parsing after }}

In terms of performance, I think this can be quite efficient: only one single loop over the template string is required. (Can this be more efficient than the actual double regexp .replace() ? :))

Does this look OK for you?

[IgorMinar]

I suppose that's better than what we have today, but you'll still do the wrong thing for:

<div> {{ <span>fadsf</span> }}</div>

or even:

<div foo="{{bar" baz="{a:{b: 'c'}}"> </div>

I wonder if three regexp replacements with expressions like:

• /"[^"]*(\{\{)[^"]*(\}\})"/ (for foo="{{bar}}")
• /'[^']*(\{\{)[^']*(\}\})'/ (for foo='{{bar}}')
• /\>[^\>]*(\{\{)[^\<]*(\}\})\</ (for <foo>{{bar}}</foo>)

wouldn't be better (the expressions likely need some tweaking but you get the idea).

[frederic-bonjour]

I got the idea :)
But what about a template like this?

<div> {{foo}} is a {{bar}} </div>

[frederic-bonjour]

I think that parsing the template directive for denormalization just like the way it is parsed in $interpolate (with a bunch of while, startIndex, endIndex and indexOf...) could be more reliable.