P.S может кто сталкивался с кастомными айдишниками для моделей? Проблема в том что idAttribute позволяет задать своё поле в качестве идентификатора, но не позволяет указать вложенное поле, например сериализованный документ из монги имеет айдишник _id.$oid На проекте по быстрому добавил в лоб его, но не хорошо иметь патчиный вариант у себя. Меня только смущает что я один такой…
если кому-то сильно трудно читать официальные: backbonejs.ru
она достаточно свежая. батя грит — малаца, хорошо зделали.
Что могу сказать. Он великолепен. Да. Полтора десятка моделей, и все по одной строке, и строки по 4 коллекции к ним, и все интегрировано с REST Framework на Django. Все быстро подхватывается и летает. В общем геммороя снимает вагон и маленькую тележку. Даже при хорошей разработке, с минимумом кода на чистом JS — все равно это лаконичнее и проще.
Чего мне пока не хватает. Увы, но я так и не нашел способа, как заставить вьюху реагировать на изменение коллекции. Не на change:attr, а на fetch и reset. Хотя тут есть и несколько довольно ясные ограничения. fetch — по сути простой AJAX запрос, и асинхроннен, но можно было бы event крутить. Почему мне такой подход не удобен: причина проста. Чтобы сделать реакцию на fetch, надо в fetch передавать объект с полем success, которое будет вызывать render вьюхи. Но у нас то коллекция во вьюху "вложена", а не наоборот. Вполне возможно что плохо искал, но задача весьма тривиальна, и говорить "плохое проектирование" тут не катит. Банальное обновление селектов, которые должны только получать те или иные коллекции с сервера и все. Не больше. Ну да ладно. Небольшой метод во вьюхе все решает, как и собственные классы handlebar'ов, от которых потом наследоваться легко, просто и приятно.
Что еще не хватило. Тут вполне может быть и где-то криво спроектировано, но все же. Что имею. Большая форма. В ней много полей. Многие поля строятся по справочникам, которые по REST тянутся с сервера. Справочники рендерятся по разному (кто в select, кто список checkbox, кто еще как-то). Делать вьюху, которая бы рулила двумя десятками коллекций, и отвечала за рендеринг каждой — явно не то. Сделал несколько маленьких вьюх. И одна большая, которая отвечает за всю форму целиком, и рулит этими мини-вьюхами. Вроде получше, чем отброшенный вариант. Что смутило — по сути эта вьюха выступает еще и контроллером. То есть наступило смешение паттерна. Хотя и задача вполне такая специфичная. Не каждый день такой сложности формы с таким количеством обмена данными.
Собственно, смутило вот это нагромождение, и логики отображения и управления другими подчиненными вьюхами. Но это скорее специфика задачи. Но опять таки. Если бы не backbone — результат я уже прекрасно знаю, ибо проходил, и до этого реализовывал тот же интерфейс без REST и Backbone. (Точнее с кусочком REST).
В остальном же, средства backbone и coffeescript позволили так лаконично, красиво и классно организовать код даже вот этой громадины, что нарадоваться не могу.
Сейчас представляю, что было бы, если бы взяли SproutCore, как изначально подумывали. Я бы на этом JS и повесился бы к чертям. А backbone со своей легкостью и простотой выдержал испытание извращением даже такой сложности. И сказать, что выдержал достойно — ничего не сказать. Он прошел через Триумфальную арку.
Еще один пост восхищения и позитива за сегодня. ))) Только больно сумбурный и неясный, но вот так вот получилось.