Comments 33
Спасибо за то, что делителсь своим опытом. Был вчера на митапе, очень понравилась ваша презентация.
Спасибо! Я мало выступаю и очень рад это слышать.
И я постараюсь подготовить ещё интересного материала к следующей встрече.
TastyPie сырой ужасно
1. Все OneToMany и ManyToMany поля приходится заполнять в dehydrate иначе начинаются проблемы когда tastypie пытается сохранять related объекты
2. Нет нормальной возможности валидации прав на сейве. Пришлось писать кучу оберток для прокидывания request в full_hydrate например.
А в целом — нормально, если нужно каркас накидать.
PS Еще в связке tastypie + backbone нужно пофиксить метод save ибо после создания объекта сервер не отдает никаких данных, посему нужно получить данные с сервера самостоятельно.
joshbohde.com/blog/backbonejs-and-django — тут код есть
Да tastypie действительно сырой. Мы от него откажемся и сделаем свой, в нём не устраивает:
1) производительность
2) реализация фильтров и ограничений авторизации.

По поводу прокидывания request в dehydrate. такая функциональность совершенно не понадобилась, всё смогли сделать через apply_authorization_limits.

Валидация очень удобно построена с помощью Django Forms, но её пришлось впилить в код Resource.

Ещё немного камней в огород tastypie. Если вчитаться в код put_list'а можно увидеть что в случае ошибки при update из базы будут удалены все записи которые update'ились и никакой информации не останется — короче это источник потери данных.

Но у коллекций нету метода save! Как вы их сохраняете?
Мы написали метод, который находит модели в коллекции, которые были созданы, изменены или удалены. И затем мы делаем три запроса, в которых участвуют только эти модели. Таким образом, мы можем легко работать с большими объёмами данных.

Правильно, потому что логичней будет работать атомарно с отдельным инстансом модели за раз. Отредактировали — отправили изменения.
На самом деле, мы отправляем массив моделей.
Если пользователь изменил 10 моделей из 100, то все 10 уйдут PUT-запросом.
Если пользователь удалил 2 модели из 100, то 2 уйдут DELETE-запросом.
Ок, понял.
Интересно будет посмотреть вашу реализацию.
А не лучше ли отправлять все 12 одним POST запросом, в котором в некоторых моделях стоит _delete: true?
Такой подход есть в рельсах и он очень удобен.
HTTP медленный и это приходится учитывать.

Тем более, что можно расценивать это не как склеенное обновление нескольких объектов, а как апдейт мастер-объекта, у которого просто есть коллекция.
А каким образом вы удаляете два экземпляра одним DELETE запросом? Это же не правильно с точки зрения RESTful? Или вы не очень строго придерживаетесь RESTfull принципов?
Удаление довольно редкая операция.
Но даже в этом случае, можно передать id через запятую.

И мы не строгие в плане REST.
Принцип «меньше запросов» — намного существеннее.
Как решили момент конфликта конвенций стиля кода? Имею ввиду то что в питоне подчеркивание, в JS — camelCase. Вариант предложенный у них на сайте с автоматическим переводом подчеркиванием в кемелКейс отметаем сразу, как не прозрачный.
Мы оставили нижнее подчёркивание.
Во-первых, свойств с несколькими словами немного.
Во-вторых, в Backbone.js всё происходит через set/get и такая конструкция не вызывает смущения:
Model.get('some_prop');
Ну допустим если предавать в шаблон underscore.js model.getJSON() то уже немного не айс.
Но я понял вашу точку зрения.
Мне очень интересны подобные технологии.
Тоже подобную методику использую, только у меня «основой» страницы является не приложение (app), а (независимые) объекты на странице, которые имеют личную область отображения, свои шаблоны, свои методы, свою логику, и могут быть вложенными в другие объекты.
К примеру страница «список постов», в вашем случае (как я понял) приложение будет управлять и отрисовывать целиком список постов, у меня каждый пост сам по себе. Или вот ещё хороший пример -«блок пользователя» который обычно отображается на каждой странице, логический должен быть отдельным объектом, который без необходимости не «перерисовывается» при хождении по ajax приложению.
В принципе, у нас так и устроено.

К примеру, App имеет несколько блоков: contentBlock, userBlock.
Когда модель user изменится, то перересуется userBlock.
Когда нужно отрисовать страницу, то меняется содержимое contentBlock.

И это суть ajax-based приложения, без этого никак, да :-)
Как у вас устроена идентификация однотипных объектов которым принадлежит сигнал? например нужно пометить один из постов на странице: при этом в команде указывается ид объекта (<a onclick=«post.do_mark(123)»)? или что-то типа (<a onlick=«post.do_mark()») при этом отрабатывает целевой объект.?
View является абстракцией DOM-элемента.

То есть создавая вью, я создаю некий div.
В его свойствах я указываю:
events: 'click': 'mark'

И в методе mark я получу view как контекст.
Всё просто и удобно :-)
Вопрос — как вы наследуете страницы от PageView? Я имею ввиду код — штатный extend делает не то что надо.
3. добавить кусочек HTML-шаблона

интересует, как вы загружаете HTML-шаблоны на страницу — все сразу при загрузке приложения или каждый кусочек отдельно по первому запросу этой страницы?
Все сразу, в коде основной страницы.
Они обёрнуты в тег script с типом text/template, что препятствует обработке этих тегов.

Также, каждый из этих тегов имеет id, который позволяет легко обращаться к коду шаблона.
А как с браузерами дружит, неприятных сюрпризов не всплывало?

Недавно случайно получилось нечто очень похожее на backbone.js.
Менеджеры коллекций, менеджеры экземпляров, напрямую завязанные на REST взаимодействие с сервером, стек изменененных элементов и хранилища коллбеков из Элементов наверх, привязанные к менеджеру коллекций (например экземпляру нужно дернуть менеджер коллекции обнулить параметр у всех членов коллекции и сохранить)

Настороженно отношусь к штукам вроде django-tastypie и вообще созданию сквозного model штыря. Да, нам помогают выдать и получить json/xml, но это и так просто, а вот поддерживать дружбу API-обертки, с усложняющейся моделью может оказаться сложновато.
Различий в браузерах пока не встречал.
Наверное, потому что используется jQuery и underscore.js, которые как раз и обеспечивают совместимость.

По поводу tastypie я, как фронтендер, много сказать не могу.
Как мне кажется он не совсем сквозной, это просто удобная прослойка для выдачи/сохранения некоторых полей моделей. Правда, он не даёт всего необходимого функционала и мы хотим своё решение.
Клево, значит беру в работу.

Tastypie похож на облегченную версию Piston, поработав с последним я понял, что в принципе решается несуществующая проблема и при этом создается новая в виде еще одного слоя абстракции. В итоге у меня просто есть приложение /a/ в котором объявлен специальный класс вьюшки, заточенный на прием и выдачу json ((де)сериализация, заголовки и т.д.) с объявленной операцией и сущностью (crud). Что и как связано с моделью расписывается непосредственно во вьюхе
Мы дошлифуем этот компонент, приведём его в красивый вид и поделимся со всеми от лица фронтендеров Островка.


Еще планируете поделиться?
Only those users with full accounts are able to leave comments. Log in, please.