Comments 36
Зачем они применили нестандартные атрибуты я не очень понял. Не XML же.
+1
А что в этом плохого? HTML это не XML (да да ваш К.О.), следовательно нам нет необходимости передавать избыточный контент только для того что бы HTML был XML совместимым. Или вы собираетесь свои страницы xml парсером утюжить?
+4
так-то есть стандартные атрибуты data- бери их и делай что хочешь.
А про XML — в XML как раз «делай что хочешь, только уведоми».
А про XML — в XML как раз «делай что хочешь, только уведоми».
+3
При использовании AngularJS можно все аттрибуты фреймворка писать с префиксом data, это поддерживается.
0
это отлично, только официальная демонстрация даёт плохой пример.
0
Их можно использовать с префиксом «data-», если очень хочется.
0
Со временем Гуголь их сделает стандартными. W3C долго сопротивляться не сможет. :-).
0
Лично меня раздражают дополнительные аттрибуты в html / шаблонах. Сперва мы уходим от всяких onclick, onsubmut и т.д., а теперь возвращаемся? Да еще и используется куча невалидных аттрибутов.
Как по мне стоит все же придерживаться стиля Backbone.js
Как по мне стоит все же придерживаться стиля Backbone.js
+2
опыт mail.ru, впрочем, показал, что onclick, например, это вовсе даже и не плохо.
0
Если кто не понял, я об этом: habrahabr.ru/company/mailru/blog/136899/ Похоже, слово mail.ru это такой катализатор.
+2
Куча невалидных атрибутов, как писалось в статье и комментариях выше, легко превращается в кучу валидных.
А возвращаемся мы не к тому же самому, а к немного другому более гибкому варианту, т.к. и те которые есть директивы — мощнее и гибче, да и свои можно разрабатывать.
> Как по мне стоит все же придерживаться стиля Backbone.js
Само собой, дело вкуса. Но, как по мне :), так у AngularJS все лаконичнее, boilerplate кода меньше.
А возвращаемся мы не к тому же самому, а к немного другому более гибкому варианту, т.к. и те которые есть директивы — мощнее и гибче, да и свои можно разрабатывать.
> Как по мне стоит все же придерживаться стиля Backbone.js
Само собой, дело вкуса. Но, как по мне :), так у AngularJS все лаконичнее, boilerplate кода меньше.
0
А мне понравилось, идея и воплощение интересные. Думаю попробую в следующем проекте.
0
Подскажите, где почитать о том как в подобных приложениях (где практически вся логика на клиенте) реализовать аутентификацию и авторизацию?
0
я нашёл в сети только это решение www.espeo.pl/2012/02/26/authentication-in-angularjs-application
0
А как реализуется аутенфикация и авторизация у клиентских приложений? Посредствам API на серверной стороне. Например на запрос по логину и паролю, в случае успеха разумеется, приходит рандомный токен, который вы должны передавать в заголовках при каждом запросе к серверу. Так же через серверный API можно проверять есть ли у пользователя разрешение на выполнение определенных действий.
+1
А token хранить в куках?
0
Мне нравится идея с хранением этого добра в LocalStorage. Если на сайте нету возможности произвести какую-либо инъекцию кода, то и получить данные из LocalStorage не выйдет. Быть может я и не прав, у меня было не так много проектов где этот вопрос встречался.
0
Против инъекций есть http-only cookies.
+3
Они передаются в ajax-запросах?
0
Конечно
0
Что вы думаете об архитектуре API Вконтакте?
Если пойти по такому пути, с прицелом на то, что в дальнейшем API также будет использоваться в iOS-приложении?
Если пойти по такому пути, с прицелом на то, что в дальнейшем API также будет использоваться в iOS-приложении?
0
Если это конкретно мне — я не работал с апи вконтакте)
Но, посмотрев доки, могу сказать (может я и ошибаюсь) — оно довольно неудобное
Но, посмотрев доки, могу сказать (может я и ошибаюсь) — оно довольно неудобное
0
это вопрос ко всем.
Тогда уточняю вопрос чьё API можно взять за образец?
Тогда уточняю вопрос чьё API можно взять за образец?
0
добавил по этой теме отдельный вопрос habrahabr.ru/qa/22392/
0
Ну во-первых можно почитать статьи, например www.ibm.com/developerworks/webservices/library/ws-restful/
Недавно работал с апи highrise, ничего сверхъестественного, но там и не нужно, все просто и удобно. Думаю есть примеры и получше, с более сложными моделями данных
Недавно работал с апи highrise, ничего сверхъестественного, но там и не нужно, все просто и удобно. Думаю есть примеры и получше, с более сложными моделями данных
+1
Столько JS-велосипедов в последнее время, не перестаёшь удивляться.
+2
Как-то много всего наворотили. Как бы в этом всем не погрязнуть. Опять свой forEach… зачем…
Почему $scope это не this? Или this там еще для чего то можно использовать?
Ну с другой стороны не надо писать var self = this;. Но не знаю… не уверен… надо пробовать…
Почему $scope это не this? Или this там еще для чего то можно использовать?
Ну с другой стороны не надо писать var self = this;. Но не знаю… не уверен… надо пробовать…
0
Честно говоря, я не знаю точных ответов на Ваши вопросы. Просто мои мысли.
По forEach: подозреваю это следствие позиционирования библиотеки как комплексной, предоставляющей сразу большинство инструментов, необходимых для разработки, без внешних зависимостей. Например, angular.element вернет Вам по умолчанию свою jquery-совместимую облегченную обертку, но если Вы подключали jQuery — получите полноценный jQuery объект.
По this и $scope: разница будет на уровне конструктора контроллера.
«Previous versions of Angular (pre 1.0 RC) allowed you to use this interchangeably with the $scope method, but this is no longer the case. Inside of methods defined on the scope this and $scope are interchangeable (angular sets this to $scope), but not otherwise inside your controller constructor.»
По forEach: подозреваю это следствие позиционирования библиотеки как комплексной, предоставляющей сразу большинство инструментов, необходимых для разработки, без внешних зависимостей. Например, angular.element вернет Вам по умолчанию свою jquery-совместимую облегченную обертку, но если Вы подключали jQuery — получите полноценный jQuery объект.
По this и $scope: разница будет на уровне конструктора контроллера.
«Previous versions of Angular (pre 1.0 RC) allowed you to use this interchangeably with the $scope method, but this is no longer the case. Inside of methods defined on the scope this and $scope are interchangeable (angular sets this to $scope), but not otherwise inside your controller constructor.»
0
Показательно то, что разработчики Google предпочли хостить этот проект на GitHub, а не на собственном Google Code.
0
Ну я думаю это были не одни и те же разработчики, и я думаю, все понимают, что гитхаб гораздо удобней
0
Sign up to leave a comment.
AngularJS — фреймворк для динамических веб-приложений от Google