Я бы так не сказал, под виндой я может быть и стал бы использовать WebMatrix, но все таки под никсами окружение гибче и понятнее. И судя по тому что expressstarter.azurewebsites.net/ ругается на отсутствие модуля express, не так уж все гладко под виндой :)
Я правильно понимаю, что нужно просто подключить эту либу и мое приложение, к примеру на backbone c pushState роутером, будет работать во всех браузерах без fallback-а на хеши?
А почему именно Rails? Незнание фреймворка, непонимание ООП прочее — по-моему вполне общие проблемы. Мне даже кажется, что изложенные здесь ошибки чаще в пхп проектах встречаются, всетаки рельсы пока не настолько популярны
Я кстати играл с этой программкой, причем я как раз брал у неё фору 4 камня. Она меня разделала :( Правда я утешал себя тем что игра была с очень неудобным для меня контролем времени, почти блиц, а я не люблю быстрые партии играть, но факт остается фактом, играет она сильно…
Разница между профессиональными данами не соответствует количеству камней форы, считается что разница между 1д и 9д около 3-х камней, так что можно сказать, что программа играет на уровне очень сильного любителя. Но тем не менее это все равно очень круто… Когда я начинал играть лет 5 назад, программы даже на 1-й разряд не играли, а сейчас получается уже на уровне гроссмейстера могут играть.
Во-первых, не надо путать Backbone.Events и события DOMа, это разные вещи. А что касается линков на модели, в чем проблема? View служит для формирования отображения модели, так что иметь ссылку на модель просто обязана, и все легко делается как раз простой однострочной декларацией this.model.bind('change', this.render, this); в методе initialize.
шаблоны в отдельных файлах — это значит что они в отдельных файлах, и они кешируются и подгружаются когда необходимо, а не добавляются в DOM заранее. Когда шаблонов много, это имеет смысл.
я про наследование от собственных вьюх, типа var ChildPopupView = PopupView.extend
Для меня этот момент был не очевиден. На моем первом проекте все вьюхи наследовались напрямую от Backbone.View, так что я решил написать об этом.
По поводу задачи, ну это просто какой-то бла-бла-бла, я если честно не понял в чем проблема… Если считаешь что тут есть какие-то принципиальные трудности, ну напиши об этом сам, порадуй людей.
На счет реальных сложностей с которыми я сталкивался, есть проблема с подключением шаблонов хранящихся в отдельных файлах, нчтоб решить эту задачу я немало времени убил, вот на эту тему пожалуй напишу как-нибудь.
Кстати, я наверно воспользуюсь идеей хранения отдельного списка окон. Только наверно лучше будет реализовать его как хеш с z-index-ами в качестве ключей, так всякие «всплывания» будут прозрачнее выглядеть.
На мой взгляд — это спорное решение. Я считаю, в моделях всетаки должны храниться сущности предметной области, а попап — только один из способов представления модели или списка моделей. В моем последнем проекте куча попапов и там рендерится все подряд, к примеру попап для отправки приглашения выглядит как-то так:
var invitationPopup = new InvitationPopupView({
user: app.user,
invitedUser: this.selectedUser,
event: this.currentEvent
});
Тут все понятно, для юзеров и ивентов естественно есть модели, но хранить свойства попапа в модели имхо немного странно.
А на счет того что статей много, я вот например не видел на хабре рецептов по организации наследования в backbone, так что надеюсь кому-нибудь статья поможет.
Это прикольно конечно, но лично мне не хотелось бы подобную магию увидеть в коде с которым я работаю
Для меня этот момент был не очевиден. На моем первом проекте все вьюхи наследовались напрямую от Backbone.View, так что я решил написать об этом.
По поводу задачи, ну это просто какой-то бла-бла-бла, я если честно не понял в чем проблема… Если считаешь что тут есть какие-то принципиальные трудности, ну напиши об этом сам, порадуй людей.
На счет реальных сложностей с которыми я сталкивался, есть проблема с подключением шаблонов хранящихся в отдельных файлах, нчтоб решить эту задачу я немало времени убил, вот на эту тему пожалуй напишу как-нибудь.
На мой взгляд — это спорное решение. Я считаю, в моделях всетаки должны храниться сущности предметной области, а попап — только один из способов представления модели или списка моделей. В моем последнем проекте куча попапов и там рендерится все подряд, к примеру попап для отправки приглашения выглядит как-то так:
Тут все понятно, для юзеров и ивентов естественно есть модели, но хранить свойства попапа в модели имхо немного странно.