Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
TastyPie сырой ужасно
1. Все OneToMany и ManyToMany поля приходится заполнять в dehydrate иначе начинаются проблемы когда tastypie пытается сохранять related объекты
2. Нет нормальной возможности валидации прав на сейве. Пришлось писать кучу оберток для прокидывания request в full_hydrate например.
А в целом — нормально, если нужно каркас накидать.
1. Все OneToMany и ManyToMany поля приходится заполнять в dehydrate иначе начинаются проблемы когда tastypie пытается сохранять related объекты
2. Нет нормальной возможности валидации прав на сейве. Пришлось писать кучу оберток для прокидывания request в full_hydrate например.
А в целом — нормально, если нужно каркас накидать.
PS Еще в связке tastypie + backbone нужно пофиксить метод save ибо после создания объекта сервер не отдает никаких данных, посему нужно получить данные с сервера самостоятельно.
joshbohde.com/blog/backbonejs-and-django — тут код есть
joshbohde.com/blog/backbonejs-and-django — тут код есть
Да tastypie действительно сырой. Мы от него откажемся и сделаем свой, в нём не устраивает:
1) производительность
2) реализация фильтров и ограничений авторизации.
По поводу прокидывания request в dehydrate. такая функциональность совершенно не понадобилась, всё смогли сделать через apply_authorization_limits.
Валидация очень удобно построена с помощью Django Forms, но её пришлось впилить в код Resource.
Ещё немного камней в огород tastypie. Если вчитаться в код put_list'а можно увидеть что в случае ошибки при update из базы будут удалены все записи которые update'ились и никакой информации не останется — короче это источник потери данных.
1) производительность
2) реализация фильтров и ограничений авторизации.
По поводу прокидывания request в dehydrate. такая функциональность совершенно не понадобилась, всё смогли сделать через apply_authorization_limits.
Валидация очень удобно построена с помощью Django Forms, но её пришлось впилить в код Resource.
Ещё немного камней в огород tastypie. Если вчитаться в код put_list'а можно увидеть что в случае ошибки при update из базы будут удалены все записи которые update'ились и никакой информации не останется — короче это источник потери данных.
Но у коллекций нету метода save! Как вы их сохраняете?
Мы написали метод, который находит модели в коллекции, которые были созданы, изменены или удалены. И затем мы делаем три запроса, в которых участвуют только эти модели. Таким образом, мы можем легко работать с большими объёмами данных.
Правильно, потому что логичней будет работать атомарно с отдельным инстансом модели за раз. Отредактировали — отправили изменения.
На самом деле, мы отправляем массив моделей.
Если пользователь изменил 10 моделей из 100, то все 10 уйдут PUT-запросом.
Если пользователь удалил 2 модели из 100, то 2 уйдут DELETE-запросом.
Если пользователь изменил 10 моделей из 100, то все 10 уйдут PUT-запросом.
Если пользователь удалил 2 модели из 100, то 2 уйдут DELETE-запросом.
Ок, понял.
Интересно будет посмотреть вашу реализацию.
Интересно будет посмотреть вашу реализацию.
А не лучше ли отправлять все 12 одним POST запросом, в котором в некоторых моделях стоит _delete: true?
Такой подход есть в рельсах и он очень удобен.
Такой подход есть в рельсах и он очень удобен.
А каким образом вы удаляете два экземпляра одним DELETE запросом? Это же не правильно с точки зрения RESTful? Или вы не очень строго придерживаетесь RESTfull принципов?
Как решили момент конфликта конвенций стиля кода? Имею ввиду то что в питоне подчеркивание, в JS — camelCase. Вариант предложенный у них на сайте с автоматическим переводом подчеркиванием в кемелКейс отметаем сразу, как не прозрачный.
Мне очень интересны подобные технологии.
Тоже подобную методику использую, только у меня «основой» страницы является не приложение (app), а (независимые) объекты на странице, которые имеют личную область отображения, свои шаблоны, свои методы, свою логику, и могут быть вложенными в другие объекты.
К примеру страница «список постов», в вашем случае (как я понял) приложение будет управлять и отрисовывать целиком список постов, у меня каждый пост сам по себе. Или вот ещё хороший пример -«блок пользователя» который обычно отображается на каждой странице, логический должен быть отдельным объектом, который без необходимости не «перерисовывается» при хождении по ajax приложению.
Тоже подобную методику использую, только у меня «основой» страницы является не приложение (app), а (независимые) объекты на странице, которые имеют личную область отображения, свои шаблоны, свои методы, свою логику, и могут быть вложенными в другие объекты.
К примеру страница «список постов», в вашем случае (как я понял) приложение будет управлять и отрисовывать целиком список постов, у меня каждый пост сам по себе. Или вот ещё хороший пример -«блок пользователя» который обычно отображается на каждой странице, логический должен быть отдельным объектом, который без необходимости не «перерисовывается» при хождении по ajax приложению.
В принципе, у нас так и устроено.
К примеру, App имеет несколько блоков: contentBlock, userBlock.
Когда модель user изменится, то перересуется userBlock.
Когда нужно отрисовать страницу, то меняется содержимое contentBlock.
И это суть ajax-based приложения, без этого никак, да :-)
К примеру, App имеет несколько блоков: contentBlock, userBlock.
Когда модель user изменится, то перересуется userBlock.
Когда нужно отрисовать страницу, то меняется содержимое contentBlock.
И это суть ajax-based приложения, без этого никак, да :-)
Как у вас устроена идентификация однотипных объектов которым принадлежит сигнал? например нужно пометить один из постов на странице: при этом в команде указывается ид объекта (<a onclick=«post.do_mark(123)»)? или что-то типа (<a onlick=«post.do_mark()») при этом отрабатывает целевой объект.?
Похоже что вы не совсем врубаетесь в то чем является Backbone.js и как он устроен. Советую прочитать вот этот пост habrahabr.ru/blogs/javascript/118782/ и все станет более понятно.
Backbone.View.events
View является абстракцией DOM-элемента.
То есть создавая вью, я создаю некий div.
В его свойствах я указываю:
И в методе mark я получу view как контекст.
Всё просто и удобно :-)
То есть создавая вью, я создаю некий div.
В его свойствах я указываю:
events: 'click': 'mark'И в методе mark я получу view как контекст.
Всё просто и удобно :-)
Вопрос — как вы наследуете страницы от PageView? Я имею ввиду код — штатный extend делает не то что надо.
3. добавить кусочек HTML-шаблона
интересует, как вы загружаете HTML-шаблоны на страницу — все сразу при загрузке приложения или каждый кусочек отдельно по первому запросу этой страницы?
интересует, как вы загружаете HTML-шаблоны на страницу — все сразу при загрузке приложения или каждый кусочек отдельно по первому запросу этой страницы?
Все сразу, в коде основной страницы.
Они обёрнуты в тег script с типом text/template, что препятствует обработке этих тегов.
Также, каждый из этих тегов имеет id, который позволяет легко обращаться к коду шаблона.
Они обёрнуты в тег script с типом text/template, что препятствует обработке этих тегов.
Также, каждый из этих тегов имеет id, который позволяет легко обращаться к коду шаблона.
А как с браузерами дружит, неприятных сюрпризов не всплывало?
Недавно случайно получилось нечто очень похожее на backbone.js.
Менеджеры коллекций, менеджеры экземпляров, напрямую завязанные на REST взаимодействие с сервером, стек изменененных элементов и хранилища коллбеков из Элементов наверх, привязанные к менеджеру коллекций (например экземпляру нужно дернуть менеджер коллекции обнулить параметр у всех членов коллекции и сохранить)
Настороженно отношусь к штукам вроде django-tastypie и вообще созданию сквозного model штыря. Да, нам помогают выдать и получить json/xml, но это и так просто, а вот поддерживать дружбу API-обертки, с усложняющейся моделью может оказаться сложновато.
Недавно случайно получилось нечто очень похожее на backbone.js.
Менеджеры коллекций, менеджеры экземпляров, напрямую завязанные на REST взаимодействие с сервером, стек изменененных элементов и хранилища коллбеков из Элементов наверх, привязанные к менеджеру коллекций (например экземпляру нужно дернуть менеджер коллекции обнулить параметр у всех членов коллекции и сохранить)
Настороженно отношусь к штукам вроде django-tastypie и вообще созданию сквозного model штыря. Да, нам помогают выдать и получить json/xml, но это и так просто, а вот поддерживать дружбу API-обертки, с усложняющейся моделью может оказаться сложновато.
Различий в браузерах пока не встречал.
Наверное, потому что используется jQuery и underscore.js, которые как раз и обеспечивают совместимость.
По поводу tastypie я, как фронтендер, много сказать не могу.
Как мне кажется он не совсем сквозной, это просто удобная прослойка для выдачи/сохранения некоторых полей моделей. Правда, он не даёт всего необходимого функционала и мы хотим своё решение.
Наверное, потому что используется jQuery и underscore.js, которые как раз и обеспечивают совместимость.
По поводу tastypie я, как фронтендер, много сказать не могу.
Как мне кажется он не совсем сквозной, это просто удобная прослойка для выдачи/сохранения некоторых полей моделей. Правда, он не даёт всего необходимого функционала и мы хотим своё решение.
Клево, значит беру в работу.
Tastypie похож на облегченную версию Piston, поработав с последним я понял, что в принципе решается несуществующая проблема и при этом создается новая в виде еще одного слоя абстракции. В итоге у меня просто есть приложение /a/ в котором объявлен специальный класс вьюшки, заточенный на прием и выдачу json ((де)сериализация, заголовки и т.д.) с объявленной операцией и сущностью (crud). Что и как связано с моделью расписывается непосредственно во вьюхе
Tastypie похож на облегченную версию Piston, поработав с последним я понял, что в принципе решается несуществующая проблема и при этом создается новая в виде еще одного слоя абстракции. В итоге у меня просто есть приложение /a/ в котором объявлен специальный класс вьюшки, заточенный на прием и выдачу json ((де)сериализация, заголовки и т.д.) с объявленной операцией и сущностью (crud). Что и как связано с моделью расписывается непосредственно во вьюхе
Мы дошлифуем этот компонент, приведём его в красивый вид и поделимся со всеми от лица фронтендеров Островка.
Еще планируете поделиться?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Базовая архитектура веб-приложения на Backbone.js