Implement angle-bracket components

[wycats]

This commit adds support for angle-bracket components, including a number of changes from curlies as discussed:

1. <my-component> is inserted with a tagName of my-component into the
   DOM. We plan to support an opt-out in the future (possibly along the
   line of the web-component is= feature).
2. Attributes specified as strings (with “quotation marks”) are inserted
   into the DOM as attributes. For the most part, this eliminates the
   need for attributeBindings.
3. Angle bracket components do not support attrs at the top-level (the
   entire attrs proxy functionality is disabled).
4. A number of other legacy behaviors are removed, such as controller=
   and string rendering.
5. Attributes are read-only values by default.

We plan to do a more aggressive disabling of legacy functionality; you should assume that by the time Ember 1.13 ships, there will be no deprecated functionality supported with angle bracket components.

From a high-level, angle bracket components are a coarse-grained opt-in for Ember 2.0 functionality.

[benkingcode]

"Angle bracket components do not support attrs at the top-level (the entire attrs proxy functionality is disabled)."

What does this mean? You couldn't set attributes on a standalone component?

[igorT]

leftover?

[locks]

@dbbk Components have attributes, what you bind in {{some-component value="hello"}} (think HTML attributes) and properties, what you define in Ember.Component.extend({ value: "hello" });. Internally Ember did some work so you could access attributes as if they were properties. After this PR lands that won't be the case anymore, and you'll have to access attributes via this.attrs.

This means for example that you can have an attribute and a property with the same name, being the property internal to the component object.

[chadhietala]

Has this been addressed #10456 or is the concept of "privately" scoped components the correct path?

[rwjblue]

@chadhietala - That will definitely need to be addressed prior to 1.13.0 final. I have labeled that issue with a milestone so that we don't loose track of it.

[rlivsey]

Does/will this support angle bracket syntax for nested components?

Previously you had to fall back to {{x-parent/x-child}} as <x-parent/x-child /> blows up, which wasn't a deal-breaker because there was no real difference to doing it that way, but now there's going to be different behaviour for the different invocations (mut etc).

[rwjblue]

@rlivsey - That was the issue that @chadhietala mentioned, it will need to be addressed for sure.

[rlivsey]

@rwjblue ah sorry didn't notice that, thanks!

[mike1o1]

Can we have an option to "fall back" to a regular HTMLElement if no component name is found, or perhaps throw a warning instead of an assert when that happens? I sometimes use "x-name" in my html and stylesheets that are nothing more than divs, and not components, but this is causing issues in the 1.13 beta branch.

[harbulot]

@rwjblue (Apologies if this is not the right place to discuss this, please let me know if I should ask about this as a new issue or forum discussion.)

I'm just wondering whether any consideration regarding XML compliance had been taken into account when it comes to this new angle-bracket notation. I know HTML5 doesn't have to be XML compliant, but it can be made to be. This is particularly useful for server-side template systems such as Genshi and Thymeleaf, which use XML-compliant templates (essentially, not too strict XHTML documents, with additional XML namespaces for server-side template elements and attributes).
The problem isn't so much about producing XML-compliant HTML (both these template systems can actually produce HTML5 that is not necessarily XML compliant, depending on their output mode).

The problem I have in mind is about being able to put Ember.js templates into XML-compliant HTML (or HTML-like) documents.

For example, this cannot be placed into an XML-based document:

<script type="text/x-handlebars">
    <button {{action 'test'}}>Test</button>
</script>

There currently is an easy workaround, a CDATA section wrapped in Handlebars comments:

<script type="text/x-handlebars">
{{! <![CDATA[ }}
    <button {{action 'test'}}>Test</button>
{{! ]]> }}
</script>

As it stands, this is not really a problem. I'm just wondering whether the angle-bracket change was part of a broader roadmap that would turn almost everything including comments into notations with angle brackets (looking like XML, but also incompatible with XML), which could make using such templates incompatible with inclusion into XML-compliant documents. I've seen older JavaScript template engines where it seemed impossible to escape this template section with comments like {{! <![CDATA[ }}...{{! ]]> }}: those could not be used with XML-based (server-side) engines.