Pull to refresh
3
0
Постевой-Черенцов Святослав @mrakolice

User

Send message
Эмм… Топов я в виду не имел, ибо до них еще расти и расти. А все остальные, яростно брызжущие слюной (или не брызжущие), получают максимум не с концертов.
Вы не правы. Отчисления с концертов минимальны. Лучшей формой в данном случае будет использование сервисов наподобие basecamp, jamendo, пресловутых itunes, googleplay и тд
Да, в процессе выполнения, потому-то все так грустно. Обычно у него есть перехватчик ошибок, который, впрочем, тоже ловит нечто невразумительное)
Как советовали в комментариях ниже — быть может, просто стоит взять 1.2.0 вместо 1.0.8.
Инжектор навернулся. Посмотрите, что у Вас с функцией stateProvider, какие проблемы в синтаксисе.
Нет, вручную $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 можно, пожалуй, еще вспомнить такую вещь:
<pre ng-bind="object_in_scope | 'json'"></pre>
Вы немножко неверно понимаете механизм scope. Рассматривайте это скорее, как область видимости, в рамках которой присутствие той или иной переменной оправдано.
Возможно, Вам понравится либа Sprache для парсинга.
В одном своем проекте я заменил самописный парсер на парсер с помощью этой либы.
В итоге код уменьшился раз в 7-8.
Имел в виду кастомные, проверил — был неправ.
У Вас ошибочная табличка. Провайдер в конфиг инжектится.
Зачем ввели новую сущность: провайдер?

Потому что у сервиса, сделанного через factory, нет доступа к секции config.

Как я думаю, это сделано ради легкого конфигурирования и разделения кода.

Нужно использовать только дефолтные настройки? Пожалуйста.
Нужно в данном конкретном приложении настроить этот провайдер вот таким образом? На здоровье.

Почему бы не задавать настройки через переменную, например? Внедряешь и настраиваешь все что хочешь

В данном конкретном случае fluent предпочтительней такого монструозного конфига. Код более структурирован и понятен.
Только что пришел в голову такой вариант:
  1. Сделать какой-нибудь сервис(фабрика или провайдер, неважно)
  2. Внутри этого сервиса написать класс с логикой
  3. Написать функцию, которая будет всегда конструировать новый объект(по сути, фабрика)
  4. Внутри контроллера при инжектировании всегда вызывать эту функцию.

В итоге будет что-то вроде этого:
app.factory('smth', function(){
  return function(){
    createNewService: function (dependencies){
        return new MyCoolService(dependencies);
    }
  }

 var MyCoolService = (function () {
                function MyCoolService() {...};
                    
                MyCoolService.prototype.coolFunction = function () {
                   ...
                };
                return MyCoolService;
            })();
})
.controller('SmthCtrl', ['$scope', 'smth', function($s, smth){
    $s._ = smth.createNewService($s);
}])


Код по классам нагло скопировал из сгенерированного TypeScript'ом, поэтому могут быть косяки.
Быть может, Вам поможет вот эта статья.

Извиняюсь, не посмотрел, что она Ваша. =)
Вы имеете в виду особенности поведения scope внутри директивы (isolate, child и scope контроллера, внутри которого эта директива используется)?
Именно библиотеку — каким-нибудь классом, внутри которого были бы необходимые функции.
В случае ангуляра этот класс выносится в отдельный модуль, который можно впоследствии подключать.

Вам будет достаточно просто реорганизовать код — сделать возвращаемую функцию фнукцией-конструктором и возвращать ее (возможно, здесь я говорю бред, потому что надо конкретно посмотреть поведение).

Быть может, Вам поможет вот эта статья.
А может, Вам нужен provider, а не factory.

Минус — придется в шаблонах обращаться к функциям и данным через _.

Это не такой уж большой минус на самом деле. Можно вместо "_" написать «innerScope» или еще что-нибудь в этом духе. "_" был выбран как минимальный более-менее адекватный идентификатор внутреннего объекта. Меньше символов — больше функциональности. =)
Ага. Я использую этот вариант. Контроллер в моем случае (да и в вашем тоже) — это функция, в которой к scope привязывается новый объект, в котором находятся все свойства, необходимые для работы в данной области видимости.

Плюсы:
— можно использовать this без боязни потери контекста
— можно сделать обычный класс, в котором есть какие-то функции, и инжектировать в него зависимости через контроллер.
— не перекрываются области видимости в случае вложенных scope.

Минусы — дополнительный уровень абстракции.

Хотя мне кажется, что это именно Ваш случай.

Пример:
angular.controller('MyCtrl', ['$scope', 'some_resource', '$oiList', function($s, s_r, oiList){
    $s._ = new oiList($s, s_r, 'modelName');
}])

oiList можно оформить как класс, scope внутри него можно использовать исключительно для специальных функций типа $apply, $emit, $eval и тд. Ну или ради функций в $rootScope.
scope._ = new Smth();

function oiList(smth){
smth.items = 'asdf';
};

Такой вариант не устраивает? У каждой scope свой внутренний объект. Каждый лист работает с этим внутренним объектом, заполняя его поля.
Насчет третьей проблемы — Вы имеете в виду вложенность некоторых scope друг в друга?
Если проблема в этом — зачем Вам сервис, когда можно сделать директиву с isolate-scope?
1

Information

Rating
Does not participate
Location
Хабаровск, Хабаровский край, Россия
Date of birth
Registered
Activity