Комментарии 29
В директивах:
Ипользуется jquery. Это вообще «хорошо»?
$(this).addClass('test');
Ипользуется jquery. Это вообще «хорошо»?
Эм, а почему нет?
ну малоли.
ng-class же православнее.
ng-class же православнее.
А. Понял, я думал, тут речь про jQuery вообще.
Если говорить про пример с классами, иногда бывает такое, что, с одной стороны, нужно добавить какой-то класс к элементу, но при этом мы знаем, что это будет происходить только один раз и больше манипуляции с классами не предвидится. В таком случае выводить логику в скоуп действительно не имеет смысла.
Если говорить про пример с классами, иногда бывает такое, что, с одной стороны, нужно добавить какой-то класс к элементу, но при этом мы знаем, что это будет происходить только один раз и больше манипуляции с классами не предвидится. В таком случае выводить логику в скоуп действительно не имеет смысла.
Ну мне и про вообще не очень понятно
toster.ru/q/132115
toster.ru/q/132115
«После создания сервисов, наверняка мне захочется воспользоваться ими в контроллерах», которые к роутерам никак не прикручены.
По моим безопытным представлениям, таких контроллеров будет большинство, а через роутер будет 1-2 контроллера.
И тогда толку от этого совета никакого.
Или я чегото недопонимаю?
По моим безопытным представлениям, таких контроллеров будет большинство, а через роутер будет 1-2 контроллера.
И тогда толку от этого совета никакого.
Или я чегото недопонимаю?
На мой взгляд, с архитектурой вашего приложения что-то не так.
По моему опыту, контроллеров, «не прикрученных» к роутеру, как раз 1-2 — те контроллеры, которые навешиваются на подгружаемые partial-view с компиляцией на лету (диалоговые окна и т.п.). Все остальные (основные) контроллеры «прикручены» к роутеру.
По моему опыту, контроллеров, «не прикрученных» к роутеру, как раз 1-2 — те контроллеры, которые навешиваются на подгружаемые partial-view с компиляцией на лету (диалоговые окна и т.п.). Все остальные (основные) контроллеры «прикручены» к роутеру.
Конкретно в голове интерфейс такой:
Страница содержит несколько вкладок (табов) по N типов объектов.
Каждая вкладка содержит: тулбар действий, фильтр, таблица обнаруженных объектов, превью выбранного объекта.
Открытие объекта создаёт новую вкладку: тулбар действий, просмотр/редактирование объекта, иногда — таблица связанных/вложенных объектов + тулбар действий с ними.
На рутере у меня, как я понимаю, 2*N контроллеров вкладок (N для «каталогов» и N для отдельных объектов)
А весь остальной ворох — это какраз partial-view, и они могут использовать разные сервисы.
Страница содержит несколько вкладок (табов) по N типов объектов.
Каждая вкладка содержит: тулбар действий, фильтр, таблица обнаруженных объектов, превью выбранного объекта.
Открытие объекта создаёт новую вкладку: тулбар действий, просмотр/редактирование объекта, иногда — таблица связанных/вложенных объектов + тулбар действий с ними.
На рутере у меня, как я понимаю, 2*N контроллеров вкладок (N для «каталогов» и N для отдельных объектов)
А весь остальной ворох — это какраз partial-view, и они могут использовать разные сервисы.
Хорошо, но жаль что не много.
Хочу добавить что ко всем не стандартным аттрибутам лучше добавлять «data-...» или «x-...» дабы не пугать HTML5 валидатор.
Например data-ng-model=..., data-ng-controller=… data-ng-cloak=…
Хочу добавить что ко всем не стандартным аттрибутам лучше добавлять «data-...» или «x-...» дабы не пугать HTML5 валидатор.
Например data-ng-model=..., data-ng-controller=… data-ng-cloak=…
Я для этого при сборке использую плагин для gulp'a под названием gulp-angular-htmlify.
И самому удобнее писать имена директив без data-префикса и валидатор ругаться не будет потом)
И самому удобнее писать имена директив без data-префикса и валидатор ругаться не будет потом)
А что это даст?
Не понял вашего вопроса.
но может ответ тут есть
stackoverflow.com/questions/18607437/should-i-care-about-w3c-validation
но может ответ тут есть
stackoverflow.com/questions/18607437/should-i-care-about-w3c-validation
Скажите, а насколько вообще перспективен этот фреймворк AngularJS? Сейчас стою перед выбором — изучать его или что-то другое, например, Prototype.
Перспективен на 19.
Что конкретно вас интересует?
Что конкретно вас интересует?
Хочу делать SPA, RIA. При этом в качестве серверной платформы планируется старый добрый Django. Не случится ли так, что вскоре декларативный подход, используемый в Angular, будет признан плохой практикой программирования и проект загнётся?
А какая разница, кем и как он будет признан? Вам шашечки или ехать?
Вопрос очень субъективный. Мне нравится, удобно. И я буду пользоваться, даже если его вдруг будут обзывать плохими словами. Если, конечно, не обнаружу что-то лучше. Такой риск есть у любого решения.
Вопрос очень субъективный. Мне нравится, удобно. И я буду пользоваться, даже если его вдруг будут обзывать плохими словами. Если, конечно, не обнаружу что-то лучше. Такой риск есть у любого решения.
А если на старый добрый напялить django-rest-framework, то будет достаточно пофиг, что на фронтенде.
http/rest пока умирать точно не собираются.
Ну и ещё, наверное, djangular, чтобы жаваскрипты аккуратно раскладывались
http/rest пока умирать точно не собираются.
Ну и ещё, наверное, djangular, чтобы жаваскрипты аккуратно раскладывались
Вы вот упомянули controllerAs, а тему не раскрыли.
А это, как раз, было бы очень интересно. Остальное уже, вроде как, де-факто.
По поводу ngInject — документация к npm-пакету говорит, что «ng-annotate follows references» и такой код
будет аннотирован автоматом.
Больше всего понравился трюк с Controller.resolve — действительно, удобно
А это, как раз, было бы очень интересно. Остальное уже, вроде как, де-факто.
По поводу ngInject — документация к npm-пакету говорит, что «ng-annotate follows references» и такой код
function MyCtrl($scope, $timeout) {
}
var MyCtrl2 = function($scope) {};
angular.module("MyMod").controller("MyCtrl", MyCtrl);
angular.module("MyMod").controller("MyCtrl", MyCtrl2);
будет аннотирован автоматом.
Больше всего понравился трюк с Controller.resolve — действительно, удобно
Тема с controllerAs былаже раскрыта в предыдущей статье.
В статье ссылки не было, поэтому я не в курсе. Дайте ссылку, плиз
В первой строчке же: habrahabr.ru/post/235873/
Скрытый текст
|-- app.js
|-- controllers/
| |-- MainCtrl.js
| |-- AnotherCtrl.js
|-- filters/
| |-- MainFilter.js
| |-- AnotherFilter.js
|-- services/
| |-- MainService.js
| |-- AnotherService.js
|-- directives/
| |-- MainDirective.js
| |-- AnotherDirective.js
Не путайте людей. Данный пример (второй из раздела «Структура проекта») — это точно такое же «Плохо», как и предыдущий первый. Подход «структурирование по типу» нельзя использовать даже в проектах с небольшой кодовой базой. Во-первых, маленькие проекты имеют тенденцию вырастать в большие, и вам впоследствии придется делать очень болезненный рефакторинг; во-вторых, это уменьшает пользу от существования единого соглашения по структуризации кода в разных проектах.
«Хорошим» примером является только третий. Причем я бы обязательно добавил, что структура должна быть рекурсивной, а не одноуровневой. Больше чтива по теме из блога разработчиков.
должна быть рекурсивной
я правильно вашу мысль понял?
|-- app.js
|-- dashboard/
| |--controllers/
| | |-- DashboardCtrl.js
| |--services/
| | |-- DashboardService.js
|-- login/
| |--services/
| | |-- LoginService.js
| |--controllers/
| | |-- LoginCtrl.js
|-- inbox/
| |--services/
| | |-- InboxService.js
| |--controllers/
| | |-- InboxCtrl.js
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Смелый стайлгайд по AngularJS для командной разработки [2/2]