Эмм… Топов я в виду не имел, ибо до них еще расти и расти. А все остальные, яростно брызжущие слюной (или не брызжущие), получают максимум не с концертов.
Вы не правы. Отчисления с концертов минимальны. Лучшей формой в данном случае будет использование сервисов наподобие basecamp, jamendo, пресловутых itunes, googleplay и тд
Да, в процессе выполнения, потому-то все так грустно. Обычно у него есть перехватчик ошибок, который, впрочем, тоже ловит нечто невразумительное)
Как советовали в комментариях ниже — быть может, просто стоит взять 1.2.0 вместо 1.0.8.
Нет, вручную $digest я, слава богу, не вызываю. Пару раз были косяки с вложенными scope.$apply, над которыми я долго думал(как обычно, функция, внутри функции внутри функции). Каюсь, я тоже страдаю криворукостью иногда)
Ваша ошибка тоже иногда случается, да)
Ну тут все просто. Основные типы ошибок, которые навскидку вспоминаются:
1. Не подключен модуль
2. В параметр директивы с вычислением ('=', '&') передается какая-то фигня.
3. Stack overflow при вызове вложенных scope.$digest
Все из этих проблем достаточно легко локализуются и исправляются. Ну хорошо, насчет легко исправляются я все-таки пошутил. =)
Ошибки легко гуглятся, а если Вам непонятно, из-за чего они возникли — опишите в комментарии. Быть может, я сталкивался с такой проблемой.
По поводу получения событий. Опишите пожалуйста, рабочую ситуацию, когда это может пригодиться.
Приведенный Вами пример включает в себя две неверные вещи при работе с ангуляром:
1. Использование angular.element в контроллере, в то время как лучше его использовать в директивах, а лучше вообще не использовать.
2. Зачем городить свой ng-class?
На самом деле, ошибок, которые стоит отлаживать, не так уж много.
Если на сайте дополнительно используется jQuery(вполне рабочая ситуация при использовании различных плагинов), то можно, например, в хроме сделать такой финт ушами:
1. Выделить элемент.
2. В консоли написать магическую строчку $($1).scope()
3. В консоль напишется значение scope, которая привязана к текущему элементу.
Почему не стоит использовать Batarang (ИМХО) — сайт начинает глючить, тормозить, и насколько мне известно, еще месяц-два назад были проблемы с утечкой памяти.
А вообще — Firebug должно хватать. Все ошибки достаточно легко локализуются обычным выключением новых директив с поиском конфликтующей (потому что проблемы возникают с их взаимодействием обыкновенно).
Из финтов ушами для получения значения внутри scope можно, пожалуй, еще вспомнить такую вещь:
Вы немножко неверно понимаете механизм scope. Рассматривайте это скорее, как область видимости, в рамках которой присутствие той или иной переменной оправдано.
Возможно, Вам понравится либа Sprache для парсинга.
В одном своем проекте я заменил самописный парсер на парсер с помощью этой либы.
В итоге код уменьшился раз в 7-8.
Потому что у сервиса, сделанного через factory, нет доступа к секции config.
Как я думаю, это сделано ради легкого конфигурирования и разделения кода.
Нужно использовать только дефолтные настройки? Пожалуйста.
Нужно в данном конкретном приложении настроить этот провайдер вот таким образом? На здоровье.
Почему бы не задавать настройки через переменную, например? Внедряешь и настраиваешь все что хочешь
В данном конкретном случае fluent предпочтительней такого монструозного конфига. Код более структурирован и понятен.
Именно библиотеку — каким-нибудь классом, внутри которого были бы необходимые функции.
В случае ангуляра этот класс выносится в отдельный модуль, который можно впоследствии подключать.
Вам будет достаточно просто реорганизовать код — сделать возвращаемую функцию фнукцией-конструктором и возвращать ее (возможно, здесь я говорю бред, потому что надо конкретно посмотреть поведение).
Быть может, Вам поможет вот эта статья.
А может, Вам нужен provider, а не factory.
Минус — придется в шаблонах обращаться к функциям и данным через _.
Это не такой уж большой минус на самом деле. Можно вместо "_" написать «innerScope» или еще что-нибудь в этом духе. "_" был выбран как минимальный более-менее адекватный идентификатор внутреннего объекта. Меньше символов — больше функциональности. =)
Ага. Я использую этот вариант. Контроллер в моем случае (да и в вашем тоже) — это функция, в которой к scope привязывается новый объект, в котором находятся все свойства, необходимые для работы в данной области видимости.
Плюсы:
— можно использовать this без боязни потери контекста
— можно сделать обычный класс, в котором есть какие-то функции, и инжектировать в него зависимости через контроллер.
— не перекрываются области видимости в случае вложенных scope.
oiList можно оформить как класс, scope внутри него можно использовать исключительно для специальных функций типа $apply, $emit, $eval и тд. Ну или ради функций в $rootScope.
Насчет третьей проблемы — Вы имеете в виду вложенность некоторых scope друг в друга?
Если проблема в этом — зачем Вам сервис, когда можно сделать директиву с isolate-scope?
Как советовали в комментариях ниже — быть может, просто стоит взять 1.2.0 вместо 1.0.8.
Ваша ошибка тоже иногда случается, да)
1. Не подключен модуль
2. В параметр директивы с вычислением ('=', '&') передается какая-то фигня.
3. Stack overflow при вызове вложенных scope.$digest
Все из этих проблем достаточно легко локализуются и исправляются. Ну хорошо, насчет легко исправляются я все-таки пошутил. =)
Ошибки легко гуглятся, а если Вам непонятно, из-за чего они возникли — опишите в комментарии. Быть может, я сталкивался с такой проблемой.
Приведенный Вами пример включает в себя две неверные вещи при работе с ангуляром:
1. Использование angular.element в контроллере, в то время как лучше его использовать в директивах, а лучше вообще не использовать.
2. Зачем городить свой ng-class?
Если на сайте дополнительно используется jQuery(вполне рабочая ситуация при использовании различных плагинов), то можно, например, в хроме сделать такой финт ушами:
1. Выделить элемент.
2. В консоли написать магическую строчку $($1).scope()
3. В консоль напишется значение scope, которая привязана к текущему элементу.
Почему не стоит использовать Batarang (ИМХО) — сайт начинает глючить, тормозить, и насколько мне известно, еще месяц-два назад были проблемы с утечкой памяти.
А вообще — Firebug должно хватать. Все ошибки достаточно легко локализуются обычным выключением новых директив с поиском конфликтующей (потому что проблемы возникают с их взаимодействием обыкновенно).
Из финтов ушами для получения значения внутри scope можно, пожалуй, еще вспомнить такую вещь:
В одном своем проекте я заменил самописный парсер на парсер с помощью этой либы.
В итоге код уменьшился раз в 7-8.
Потому что у сервиса, сделанного через factory, нет доступа к секции config.
Как я думаю, это сделано ради легкого конфигурирования и разделения кода.
Нужно использовать только дефолтные настройки? Пожалуйста.
Нужно в данном конкретном приложении настроить этот провайдер вот таким образом? На здоровье.
В данном конкретном случае fluent предпочтительней такого монструозного конфига. Код более структурирован и понятен.
В итоге будет что-то вроде этого:
Код по классам нагло скопировал из сгенерированного TypeScript'ом, поэтому могут быть косяки.
Извиняюсь, не посмотрел, что она Ваша. =)
В случае ангуляра этот класс выносится в отдельный модуль, который можно впоследствии подключать.
Вам будет достаточно просто реорганизовать код — сделать возвращаемую функцию фнукцией-конструктором и возвращать ее (возможно, здесь я говорю бред, потому что надо конкретно посмотреть поведение).
Быть может, Вам поможет вот эта статья.
А может, Вам нужен provider, а не factory.
Это не такой уж большой минус на самом деле. Можно вместо "_" написать «innerScope» или еще что-нибудь в этом духе. "_" был выбран как минимальный более-менее адекватный идентификатор внутреннего объекта. Меньше символов — больше функциональности. =)
Плюсы:
— можно использовать this без боязни потери контекста
— можно сделать обычный класс, в котором есть какие-то функции, и инжектировать в него зависимости через контроллер.
— не перекрываются области видимости в случае вложенных scope.
Минусы — дополнительный уровень абстракции.
Хотя мне кажется, что это именно Ваш случай.
Пример:
oiList можно оформить как класс, scope внутри него можно использовать исключительно для специальных функций типа $apply, $emit, $eval и тд. Ну или ради функций в $rootScope.
function oiList(smth){
smth.items = 'asdf';
};
Такой вариант не устраивает? У каждой scope свой внутренний объект. Каждый лист работает с этим внутренним объектом, заполняя его поля.
Если проблема в этом — зачем Вам сервис, когда можно сделать директиву с isolate-scope?