Pull to refresh

Comments 36

Зачем они применили нестандартные атрибуты я не очень понял. Не XML же.
А что в этом плохого? HTML это не XML (да да ваш К.О.), следовательно нам нет необходимости передавать избыточный контент только для того что бы HTML был XML совместимым. Или вы собираетесь свои страницы xml парсером утюжить?
так-то есть стандартные атрибуты data- бери их и делай что хочешь.

А про XML — в XML как раз «делай что хочешь, только уведоми».
При использовании AngularJS можно все аттрибуты фреймворка писать с префиксом data, это поддерживается.
это отлично, только официальная демонстрация даёт плохой пример.
Скорее они не видят в этом настолько серьезной проблемы и серьезно относятся к тому, что на базе HTML и AngularJS можно сделать DSL для своего приложения. Потому, возможно, для себя не видят смысла в полумерах, если уж собираются нестандартные элементы использовать.
Их можно использовать с префиксом «data-», если очень хочется.
Со временем Гуголь их сделает стандартными. W3C долго сопротивляться не сможет. :-).
Лично меня раздражают дополнительные аттрибуты в html / шаблонах. Сперва мы уходим от всяких onclick, onsubmut и т.д., а теперь возвращаемся? Да еще и используется куча невалидных аттрибутов.
Как по мне стоит все же придерживаться стиля Backbone.js
опыт mail.ru, впрочем, показал, что onclick, например, это вовсе даже и не плохо.
Куча невалидных атрибутов, как писалось в статье и комментариях выше, легко превращается в кучу валидных.

А возвращаемся мы не к тому же самому, а к немного другому более гибкому варианту, т.к. и те которые есть директивы — мощнее и гибче, да и свои можно разрабатывать.

> Как по мне стоит все же придерживаться стиля Backbone.js
Само собой, дело вкуса. Но, как по мне :), так у AngularJS все лаконичнее, boilerplate кода меньше.
А мне понравилось, идея и воплощение интересные. Думаю попробую в следующем проекте.
Подскажите, где почитать о том как в подобных приложениях (где практически вся логика на клиенте) реализовать аутентификацию и авторизацию?
А как реализуется аутенфикация и авторизация у клиентских приложений? Посредствам API на серверной стороне. Например на запрос по логину и паролю, в случае успеха разумеется, приходит рандомный токен, который вы должны передавать в заголовках при каждом запросе к серверу. Так же через серверный API можно проверять есть ли у пользователя разрешение на выполнение определенных действий.
Мне нравится идея с хранением этого добра в LocalStorage. Если на сайте нету возможности произвести какую-либо инъекцию кода, то и получить данные из LocalStorage не выйдет. Быть может я и не прав, у меня было не так много проектов где этот вопрос встречался.
Против инъекций есть http-only cookies.
Они передаются в ajax-запросах?
Что вы думаете об архитектуре API Вконтакте?
Если пойти по такому пути, с прицелом на то, что в дальнейшем API также будет использоваться в iOS-приложении?
Если это конкретно мне — я не работал с апи вконтакте)
Но, посмотрев доки, могу сказать (может я и ошибаюсь) — оно довольно неудобное
это вопрос ко всем.
Тогда уточняю вопрос чьё API можно взять за образец?
Ну во-первых можно почитать статьи, например www.ibm.com/developerworks/webservices/library/ws-restful/

Недавно работал с апи highrise, ничего сверхъестественного, но там и не нужно, все просто и удобно. Думаю есть примеры и получше, с более сложными моделями данных
Столько JS-велосипедов в последнее время, не перестаёшь удивляться.
Как-то много всего наворотили. Как бы в этом всем не погрязнуть. Опять свой forEach… зачем…
Почему $scope это не this? Или this там еще для чего то можно использовать?
Ну с другой стороны не надо писать var self = this;. Но не знаю… не уверен… надо пробовать…
Честно говоря, я не знаю точных ответов на Ваши вопросы. Просто мои мысли.

По 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.»
Показательно то, что разработчики Google предпочли хостить этот проект на GitHub, а не на собственном Google Code.
Ну я думаю это были не одни и те же разработчики, и я думаю, все понимают, что гитхаб гораздо удобней
и google code закрывается, кажется
Закрыли Google Code Search, а с Google Code всё в порядке.
GitHub социальнее. Думаю для этого проекта это большой плюс.
Ну помимо этого он еще и просто удобнее, я имею ввиду гуй
Sign up to leave a comment.

Articles