Unable to access filters with special characters from templates

[thirtyseven]

At HEAD, it is not possible to access filters with "." or "-" characters in their names from templates. The filter parsing will stop at the first non-alpha character and the compiler will try to look for a filter with that name.

i.e., {{foo|bar.baz}} will have the compiler look for a filter named bar instead of bar.baz.

The filter can still be accessed with the $filter service.

I'm working on a unit test for this.

[pkozlowski-opensource]

The problem is that all the special chars that have meaning in expression (I think that you would run into troubles not only with -, . but also with [ etc.) are really confusing. While I think we could fix it (didn't look at the code, so just guessing here) I'm not sure we want.

I mean - bar.baz "looks" like an expression and not as an identifier referring to a filter by name.

For now I'm marking this as "won't fix" but let's hear what other people got to say. @lgalfaso @caitp ?

[gkalpak]

BTW, the . seems to work fine on 1.3.2: Demo fiddle
(The - not so much...)

[pkozlowski-opensource]

Yeh, and doesn't with the latest snapshot: http://jsfiddle.net/6xnxuh0e/1/ so as you can see this is very impl specific atm. The real question is this: do we want to support this? My take at it would be no.

[lgalfaso]

This looks like an invalid use case. I agree with making this a won't fix

[thirtyseven]

Shouldn't an error be thrown then when you try to register a filter with an invalid name? Right now, there isn't an error when you register the filter, it works when you use $filter, but when you use the filter in the template, you get a meaningless error about fooFilterProvider not being found for a filter called foo.bar.

BTW, there is a filter with a name like this in the Google codebase, the dot is used as a sort of namespace.

[thirtyseven]

At the very least this should probably be included in the release notes for 1.3.3 as a backwards incompatible change. We've been using the dotted filter since 1.0 and I'm sure there will be a few other people surprised by this.

[pkozlowski-opensource]

@thirtyseven we could definitively add it to the breaking changes in 1.3.3. We will need to do it by hand though, as the commit that brings this change is in already.

[enapupe]

Minor updates shouldn't be backwards compatible? To me it makes no sense have this code working on 1.3.0 but not on 1.3.3.

[pkozlowski-opensource]

@enapupe I definitively agree on the principle. The only thing is that it was working "by accident" - that is - I don't believe that that it was the original intention to support filters with dots in their names. The best proof for this is that we haven't had any tests for this case and some internal, perf-related refactorings change the non-explicit behavior.

I see this change more like a bug fix that aligns the code with the initial intention. But I guess we should add it to the docs as people seem to bump into those things.

I'm going to re-open this issue so we can add a note to the changelog.