Comments 11
Насчет третьей проблемы — Вы имеете в виду вложенность некоторых scope друг в друга?
Если проблема в этом — зачем Вам сервис, когда можно сделать директиву с isolate-scope?
Если проблема в этом — зачем Вам сервис, когда можно сделать директиву с isolate-scope?
Дело не в этом. $scope один и тот же, просто в моем случае используется напрямую внутри функции (передаю как параметр). Но хотелось бы в функции работать не со $scope, а с внутренним объектом, который затем можно было бы присвоить $scope.
Сейчас делается так:
function oiList (scope) {
scope.items = 'model'
}
oiList($scope)
Хочется так:
scope.items = function oiList () {
return 'model'
}
Сейчас делается так:
function oiList (scope) {
scope.items = 'model'
}
oiList($scope)
Хочется так:
scope.items = function oiList () {
return 'model'
}
scope._ = new Smth();
function oiList(smth){
smth.items = 'asdf';
};
Такой вариант не устраивает? У каждой scope свой внутренний объект. Каждый лист работает с этим внутренним объектом, заполняя его поля.
function oiList(smth){
smth.items = 'asdf';
};
Такой вариант не устраивает? У каждой scope свой внутренний объект. Каждый лист работает с этим внутренним объектом, заполняя его поля.
Не очень понимаю, что это за подчеркивание. В нем мы теперь будем хранить модель данных?
Ага. Я использую этот вариант. Контроллер в моем случае (да и в вашем тоже) — это функция, в которой к scope привязывается новый объект, в котором находятся все свойства, необходимые для работы в данной области видимости.
Плюсы:
— можно использовать this без боязни потери контекста
— можно сделать обычный класс, в котором есть какие-то функции, и инжектировать в него зависимости через контроллер.
— не перекрываются области видимости в случае вложенных scope.
Минусы — дополнительный уровень абстракции.
Хотя мне кажется, что это именно Ваш случай.
Пример:
oiList можно оформить как класс, scope внутри него можно использовать исключительно для специальных функций типа $apply, $emit, $eval и тд. Ну или ради функций в $rootScope.
Плюсы:
— можно использовать 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.
Ага, понял! Подумывал о подобной штуке. Вполне себе вариант. Плюс в том, что всё изолированно. Минус — придется в шаблонах обращаться к функциям и данным через _.
Если уйти от нюансов и посмотреть свысока, как бы вы решили подобную задачу? Т.е. организовали библиотеку функций для работы со списками?
Если уйти от нюансов и посмотреть свысока, как бы вы решили подобную задачу? Т.е. организовали библиотеку функций для работы со списками?
Именно библиотеку — каким-нибудь классом, внутри которого были бы необходимые функции.
В случае ангуляра этот класс выносится в отдельный модуль, который можно впоследствии подключать.
Вам будет достаточно просто реорганизовать код — сделать возвращаемую функцию фнукцией-конструктором и возвращать ее (возможно, здесь я говорю бред, потому что надо конкретно посмотреть поведение).
Быть может, Вам поможет вот эта статья.
А может, Вам нужен provider, а не factory.
Это не такой уж большой минус на самом деле. Можно вместо "_" написать «innerScope» или еще что-нибудь в этом духе. "_" был выбран как минимальный более-менее адекватный идентификатор внутреннего объекта. Меньше символов — больше функциональности. =)
В случае ангуляра этот класс выносится в отдельный модуль, который можно впоследствии подключать.
Вам будет достаточно просто реорганизовать код — сделать возвращаемую функцию фнукцией-конструктором и возвращать ее (возможно, здесь я говорю бред, потому что надо конкретно посмотреть поведение).
Быть может, Вам поможет вот эта статья.
А может, Вам нужен provider, а не factory.
Минус — придется в шаблонах обращаться к функциям и данным через _.
Это не такой уж большой минус на самом деле. Можно вместо "_" написать «innerScope» или еще что-нибудь в этом духе. "_" был выбран как минимальный более-менее адекватный идентификатор внутреннего объекта. Меньше символов — больше функциональности. =)
Быть может, Вам поможет вот эта статья.
Извиняюсь, не посмотрел, что она Ваша. =)
А если не библиотеку? У вас на сайте два списка с методами добавления/удаления элементов. Это уже повод подумать над вынесением общего кода.
Над провайдером думал, но пока не ясно что он может дать кроме предварительной настройки…
Над провайдером думал, но пока не ясно что он может дать кроме предварительной настройки…
Только что пришел в голову такой вариант:
В итоге будет что-то вроде этого:
Код по классам нагло скопировал из сгенерированного TypeScript'ом, поэтому могут быть косяки.
- Сделать какой-нибудь сервис(фабрика или провайдер, неважно)
- Внутри этого сервиса написать класс с логикой
- Написать функцию, которая будет всегда конструировать новый объект(по сути, фабрика)
- Внутри контроллера при инжектировании всегда вызывать эту функцию.
В итоге будет что-то вроде этого:
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'ом, поэтому могут быть косяки.
Sign up to leave a comment.
Набор методов для работы со списками в AngularJS