Well, maybe they should.

I left a comment on #1 (comment):

I don't have time right now to give a proper review, but I was wondering if it might also make sense to add selectors for XML namespaces, to assist in supporting SVG and MathML stuff? I guess if we need that it could be added later on, but it seems like a good idea

It may or may not be worth it, but it seems like a potentially useful thing

Following the instructions in the readme will not put the developer's machine in a state where it can run the tests. Two steps need to be added:

1. npm install -g karma
2. npm install -g karma-cli

Note: sudo needed on linux

Also, it is unclear how to run the examples. Simply opening helloworld.html in Firefox results in script errors. In the past, I've been able to run require.js-based projects just fine directly from the file system via Firefox. Something about the current configuration does not work. Please provide instructions for how to run the examples.

I am working on a project with a similar setup to this repo. I'm trying to use the traceur preprocessor for karma along with the istanbul coverage preprocessor and I ended up finding this issue on the istanbul repo. I'm opening an issue here so that...

1. There's a place to track automated coverage for the angular templating repo
2. I'll be notified once this repo has implemented a solution.

I imagine this problem will pop up a lot more when angular 2.0 is released. Thanks.

Allow to require an html file just like a js module. The new module will return the viewFactory.

• on the fly compile: hook into ES6-Loader
• precompile: via gulp / grunt task

Start: See https://github.com/angular/templating/blob/master/test/precompiler/precompiler.spec.js

Note: This is the place where the <module> tag is evaluated to find the directives that can be used in the template

This feature is not supported by Safari. It may not work in Opera either. It appears to not work on Chrome on Linux. I think we should switch this to simply parsing the text content. We can use the DOMParser directly along with a simple polyfill. Here's a link to the docs and polyfill: https://developer.mozilla.org/en-US/docs/Web/API/DOMParser

Easier to see if you increase the number of todos to about 20~

The number of listeners (from the chrome dev tool -> timeline) doubles after deleting all todos. I think ngZone is holding the references, but I'm not sure.

See https://github.com/angular/templating/blob/master/src/event_handler.js

Needs to be refactored:

• a general way of registering handlers on top level, i.e. not on view level
• use with on- (event name is not known in advance!)
• use in ngNode to detect changes in other components (event name is known in advance here)

Attention: This should be implemented so that it works fine with Shadow DOM / event retargeting!

Currently, in order to data-bind to the value of an attribute with the same name as its corresponding directive, you must duplicate the directive. So, for ng-repeat you must do the following:

<div ng-repeat="" bind-ng-repeat="items"></div>

Only the second attribute should be necessary.

Integration via properties and events is already working.

E.g. integrate with Node.bind
E.g. integrate with custom elements

The method View.watch is missing a parameter. Please add a collection:bool parameter.

Internally it is hard-coded to pass false to the watch parser for the collection indicator. This value should be passed from the View.watch method parameters instead. Without this capability it is not possible to implement ngRepeat.

attach: When all bindings have received their initial value and the node is connected to the document.body

detach: When the view is removed from document.body

Run the helloworld sample you will see the bug. Add a couple of different items. Then start invoking the "Add" button. You will see that the incCounter() is invoked a number of times equal to the node's index (+1). So if you have three items, and you click "Add" on the third item, the function will be invoked three times. (Actually, as I was writing this, I discovered that the behavior isn't consistent. It's also dependent on what button was clicked previously.)

In addition to this, there's also some dirty checking issues going on. You will notice that clicking the button doesn't always result in an update. Sometimes you will need to click another button to see the original sum update.

I already commented about that in the docs, but will post this here again as I think this issue has a greater visibility:

Why isn't server-side rendering a design goal? It would improve performance for (mobile) apps due to a better initial load time and increases compatibility with existing services (say saving a page from an Angular app to Pocket or indexing by search engines). Angulars templates and directives are often misused because of this - many people use data-binding to translate their apps even if these translations are static and not dynamic. The same happens for templates. A lot of these have static components (e.g. some ng-includes in some apps are never changed while running the app - they are just used to inline static HTML which could happen in a pre-compile step or on server side, too). I think some people call this "bind-once", but I think this is only half of the story if "bind-once" doesn't work server-side, too. And... it would be great if two-way data-bindings would be prefilled with the right values on the server-side while pushing the initial app to the browser, so you don't get "content flickering". Some people call this isomorphic JavaScript.

Link to the disscusion in the docs.

I also had a short discussion with @bradlygreen on Google+ about this topic where he stated that the "server side rendering" feature request is mostly about SEO and that this would be a solved topic and that data should be inlined to get a fast initial response:

I don't think SEO is a solved problem. As far as I understand escaped_fragment it only works for SPAs based on Angular, not for Angular code which is embedded in existing (read: legacy) pages.

Not everything can be inlined in the first template, because a lot of people misuse data-binding (e.g. for translation, even if the translated strings aren't changed at runtime and therefor are static). This unnecessarily defers execution of the app. You can - and should - precompile things like that with a different templating engine, but this often conflicts with Angular templates syntax wise and developers need to use and learn an additional templating engine.

It makes it harder to reuse code (e.g. for validation) on the server side, too. Of course I could refactor my validation code to a non-angular-based framework and than reuse it in my controllers, filter, whatever, but I can't use them out of the box and I couldn't reuse i18n filter which are already in Angulars core.

This aside it would would be super handy if I could use directives and precompile them e.g. like a static site generator. I know this is not the focus of Angular, but than I could reuse my Angular code for a lot more projects. Say I have a with an ng-repeat inside. The controller to switch the carousel items is static and will be released for a static site or a SPA alike, but ng-repeat would only be executed if is filled with real time data. If it just filled with a static JSON it could be precompiled and the generated markup is just plain vanilla HTML - or it would check async for new data and is therefor only pre-filled with data to stop "content flickering". Something which is a problem for dynamic SPAs, too.

Thank you.

The helloworld.html file contains new references to third party libraries. The casing for the folder name does not match what is present on the disk. This causes problems on some operating systems. Please change as follows:

<link rel="stylesheet" href="/third_party/brick/brick-1.0.1.byob.css">
  <script src="/third_party/brick/brick-1.0.1.byob.js"></script>

Note: It should be all lowercase.

I just watched that video and I am confused regarding the issue with the 'src' atttribute described by Rob Eisenberg at 39m30s
http://youtu.be/cwXZ0YFvpzs?t=39m30s

In Google Polymer I can do exactally <img src='{item.imgsrc}/> inside a template that and there is no erroneous http requests. The src gets evaluated only when the template is actually added to the visible DOM.

For all angular app as well as for an app that uses Angular only for one imported web component.

At present, to create a view, you must supply an execution context. Afterwards, this context is permanently tied to the view. We should separate these two things so that we can re-use view instances by re-targeting them to a different execution context. There are two primary use cases off the top of my head:

1. The router can use this to optimize rendering of frequently accessed routes. This can be done by implementing the router's corresponding directive to cache views internally and re-target them to different controller instances. In fact, any template directive could use this technique (even allowing caching behavior to be configured by the developer).
2. Performant, infinitely scrolling lists will want to create a number of view instance up front and re-use those instances by simply re-targeting each template item to different data and using some css3 transforms.

There are two implementations of linked list, one is in templating and the other is in watchtower. We should probably have a look at these and see if we can have a single implementation used in both places, then move this out to its own library.

See the related issue in watchower: angular/watchtower.js#28

The loader.js attempts to patch require.js by detecting all HTML files and prepending the module id with a custom loader plugin. However, it may be that files with an html extension have been explicitly required by the developer and aren't intended to be turned into view factories. To fix, detect whether the module id is already prepended by a loader plugin and bypass if it is.

The package "jsdom" depends on "contextify" wich have a binary module on Node.
To instal "contextify" on Windows I need to install Visual Studio and Phyton.
http://encosia.com/cheerio-faster-windows-friendly-alternative-jsdom/
It makes very hard to see the examples of "templating".

An alternative to replace "jsdom" is "cherio"
https://github.com/cheeriojs/cheerio

• digest and flush, with 2 watchGroups, dom read/dom write/async queue
• digest:
  • processes 1 watchGroup and async queue
• flush:
  • processes 1 watchGroup and dom read/dom write queue
• flush watchGroup:
  • for observers whose reaction function only changes the DOM and no one else will change that part of the DOM during flush.
  • purpose: optimize digest cycles

Also: When a change event for a DOM property is triggered, execute the reaction function of watches for that property directly .

This relates to issue #26. In order to enable caching and re-use of views, a template directive needs to be able to turn off watches on a particular view instance without destroying the view. It may be that this can be handled by simply setting the execution context to null via an API provided by #26.

So, it's been about 5 months since the last "dist" release was updated, and there are almost no tagged releases yet.

@EisenbergEffect / @tbosch do you think you guys could pick out some suitably stable commits for tagging so that prototypes can be built against relatively recent changes to the code? Not necessarily the bleeding edge, but just stable "enough" to be useful, I guess.

Filters should be defined just like directives via a class that has the @Filter annotation, e.g. @Filter({name:'multiply'}).

In a template, only those filters should be allowed in expressions that are provided via the <module> tag, just like directives (resp. when calling compile manually the allowed filter classes need to be given as an argument to compile).

Open questions:

• when a directive calls view.watch(expr...), which filters can this expression contain? Would the directive need to provide the filters as an argument to watch?
• on which injector are filters registered? On the root injector or on the view's injector?