Added support for the Blaze rendering engine. Also added a more flexible... #26
Conversation
…ble bootstrapping mechanism. Default behavior is the same as the original (bootstrapping 'ngMeteor' on the document element).
|
|
||
| <ANY ng-template="foo"></ANY> | ||
|
|
||
| <!--Add the ng-controller attribute if you want to load a controller at the same time.--> | ||
| <ANY ng-template="foo" ng-controller="fooCtrl"></ANY> | ||
|
|
There was a problem hiding this comment.
No longer need this since users only will render templates they identify with the ng-template directive. Templates are no longer pre-rendered and cached. This provides for rendering templates via meteor spacebars first and then rendering that output using angular's compile/link functionality.
Pre-rendering with render() and then caching the result was not very flexible in any case if the template was not 'static'. If you needed to generate the template contents, for example, using meteor's rendering engine, and then feed that result into the angular compile/link processor, then using the pre-rendered HTML from the templateCache would not have been helpful.
…rom page to page. Temporary 'partial fix' until memory leak issue can be solved.
…red through iron-router were overridden and lost when angular compile/digest cycle was incorporated. This fix caches any registered 'rendered' callback and reapplies it after the angular compile/digest cycle is completed and then re-registers that callback on the template.
|
@pavlovich We are a dev team that took on ourselves to support ngMeteor on this fork: |
... bootstrapping mechanism. Default behavior is the same as the original (bootstrapping 'ngMeteor' on the document element).