Внутри — может быть и одно и то же, но при написании библиотеки важно все же как это снаружи, для пользователя библиотеки.
В вашем случае описание элементов карты находится где-то в контроллере, в моем — во view, что правильнее, т.к. карта и ее элементы — это отображение. В моем подходе можно, например, применить фильтры для сериализации некой модели гео-объектов в удобный для директивы вид:
<ng-map-marker ng-repeat="geoObject in geoObjects" source="geoObject|serializeGeoObject">
Это, конечно, может быть медленнее в целом, но подход более чистый для разделения безнес-логики и вью-логики.
В свое время релизоаывал прослойку для гуглокарт. У меня была такая структура:
общая директива ng-map создавала общий scope и принимала общие конфиги для всех объектов карты, все нижеперечисленные директивы должны быть вложены внутрь данной.
ng-map-canvas для полотна карты
ng-map-marker для позиционирования маркера. Для нескольких маркеров можно использовать ng-repeat :)
ng-map-route и ng-map-route-waypoint (в сочетании с ng-repeat) для отрисовки маршрутов
ng-markers-cloud — оптимизированный вариант для показа большого количества маркеров, в ng-model можно передать массив для вывода. Из минусов — наблюдение за массивом ведется только по ссылке, изменение отдельных элементов не приведет к перерисовке.
ng-map-overlay — универсальная директива, годится как для отображения кастомных маркеров, так и для модальных окон на карте, всплывающих облачков, тултипов. Создавала оверлэй для карты, куда помещалось переданное внутри директивы html-содержимое со всеми преимуществами дата-байндинга.
Мне лично кажется, что такой подход — с описанием объектов карты в разметке более соответствует принципам фреймворка.
Да, уже нашел. Все же стоило бы отдельно упомянуть:)
По поводу неудоства работы в контроллере: если получение данных асинхронно, то в любом случае в колбэке придется с ними работать.
А какие проблемы с директивами, какой трешак? Ну, работы чуть больше выходит, да, но вот серьезных проблем при полностью правильном подходе не обнаруживал. Ну и да, ангуляр-то предназначен как раз для сингл-пейдж приоложений, не для простеньких сайтов.
Поиграйте в упомянутую выше цивилизацию, в новый xcom, в dark souls (осторожно только), в hotline miami, в faster then light. Масса интересных игр. А еще масса игр с прекрасным миром — чего только стоит «тупой боевик» бордерлэндс, которому хочется стоя аплодировать за реплики персонажей.
Не смотрели в сторону MVVM- фреймворков? AngularJS, EmberJS (может быть каких-то аналогов)? MVVM представляется более логичным и подходящим для фронт-енда по сравнению с MVC. Опять-же, верстальшики будут в восторге, да еще и смогут помимо верстки добавлять базовую динамику для вьюх.
Не все решения там хороши, но заглянуть в реализации очень полезно — узнал для себя много нового из того, чего нет или невозможно найти в документации.
И да, вообще на данный момент документация — одна из главных проблем фреймворка. Код документирован прекрасно, но на офф.сайте есть далеко не все.
В RoR-тусовке кофе уже практически стандарт. Сам вот нынешний проект таки решился писать на кофе. Да, глазам зацепиться не за что, да, местами чувствуешь себя ограниченным, но скорость разработки явно выше.
В AngularJS есть $scope.$watch("variable", function() { ... }) — в общем-то те-же observerables. А вот по поводу кастомных биндингов это вы совсем зря — есть же взиожность добавления кастомынх директив, даже на главной странице есть пример (про компоненты табов). Плюс за счет тех-же директив в ангуляре легко реализуются reusable-компоненты, с которыми в knockout была беда, насколько я понял (выбирал между двумя фреймворками).
В вашем случае описание элементов карты находится где-то в контроллере, в моем — во view, что правильнее, т.к. карта и ее элементы — это отображение. В моем подходе можно, например, применить фильтры для сериализации некой модели гео-объектов в удобный для директивы вид:
<ng-map-marker ng-repeat="geoObject in geoObjects" source="geoObject|serializeGeoObject">Это, конечно, может быть медленнее в целом, но подход более чистый для разделения безнес-логики и вью-логики.
ng-mapсоздавала общий scope и принимала общие конфиги для всех объектов карты, все нижеперечисленные директивы должны быть вложены внутрь данной.ng-map-canvasдля полотна картыng-map-markerдля позиционирования маркера. Для нескольких маркеров можно использовать ng-repeat :)ng-map-routeиng-map-route-waypoint(в сочетании с ng-repeat) для отрисовки маршрутовng-markers-cloud— оптимизированный вариант для показа большого количества маркеров, в ng-model можно передать массив для вывода. Из минусов — наблюдение за массивом ведется только по ссылке, изменение отдельных элементов не приведет к перерисовке.ng-map-overlay— универсальная директива, годится как для отображения кастомных маркеров, так и для модальных окон на карте, всплывающих облачков, тултипов. Создавала оверлэй для карты, куда помещалось переданное внутри директивы html-содержимое со всеми преимуществами дата-байндинга.Мне лично кажется, что такой подход — с описанием объектов карты в разметке более соответствует принципам фреймворка.
По поводу неудоства работы в контроллере: если получение данных асинхронно, то в любом случае в колбэке придется с ними работать.
В чем кайф:
Работаем с промисом как с обычным объектом:
Ангуляр сам дождется пока все промисы в шаблоне не будут выполнены, и только потом отрендерит его с результируюшими объектами. Красота и удобство.
Упс, выше уже ответили наполовину.
И да, вообще на данный момент документация — одна из главных проблем фреймворка. Код документирован прекрасно, но на офф.сайте есть далеко не все.
$scope.$watch("variable", function() { ... })— в общем-то те-же observerables. А вот по поводу кастомных биндингов это вы совсем зря — есть же взиожность добавления кастомынх директив, даже на главной странице есть пример (про компоненты табов). Плюс за счет тех-же директив в ангуляре легко реализуются reusable-компоненты, с которыми в knockout была беда, насколько я понял (выбирал между двумя фреймворками).