Интересно. Кажется в такую модель вполен себе можно вогнать любой уже существующий форум/чат. Хорошо выглядит идея масштабирования по ключевым узлам… Увидеть бы такое в деле, а то вас кажется хабраэффектом замело.
Для того, чтобы отключить реактивное обновление при выводе можно сделать, например, так {{unbind _page.value}}, либо, как в вашем случае, можно сделать необновляемым целый блок:
{{unbind}}
<!-- ваш html с нереактивными {{_page.values}} вставками -->
{{/}}
А для того, чтобы в определенный момент все это перерисовать нужно использовать ключевое слово on, то есть у вас будет примерно так:
На ваш вопрос по указанию времени я отвечу так — мы сами у себя используем фукнционал так называемых хуков racer-а, кто-то из создателей дерби выкладывал когда-то gist c кодом — его мы и используем в своих проектах. Специально ради ответа на ваш вопрос (хотя в принципе — давно пора), я вынес этот функционал и оформил в модуль derby-hook. В близжайшее время постараюсь сделать к нему нормальную документацию с примерами. В вашем случае будет так (нужно вносить изменения в файл server.js — см. урок #3)
var derbyHook = require('derby-hook');
// В store добавляем функцию hook
derbyHook(store);
store.hook('create', 'todos', function(docId, value, session, backend) {
model = store.createModel();
model.fetch ('todos.'+docId, function(err){
var time = +new Date();
model.set('todos.'+docId+'.ctime', time);
})
});
В «дерби-приложении», соответственно, ничего в ctime не пишите.
Поправил, спасибо. Обновился racer (там тоже альфа-версии 0.6), там немного api поменялось, а в зависимостях у дерби указано racer 0.6+. В результате derby 0.6.0-alpha6 щас вообще не заработает ни при каких условиях. Нужно сделать скиднку на то, что мы работаем с альфами — создатели об этом у себя написали — возможно изменение api.
(по поводу разделение клиента/сервера попозже напишу, после работы)
А потом можно через racer-access запретить доступ к коллекции users и пользователь сможет увидеть только то, что есть в users_small, обращаясь к ней как к обычной коллекции
По теме стоит отметить, что indexOf — вообще плохое название для действия «проверить, содержит ли массив данный элемент». Не говоря уже обо всей этой чернухе с -1. В js явно не хватает метода с номальным именем, возвращающего булево значение.
Большинство ваших пунктов снимается, если четко определить место дерби в экосистеме. Итак, дерби — это npm-модуль, которым расширяется обычное node-овское expressjs-приложение. Отсюда, например, ответим на пункт пятый: «Как с нуля настроить Ubuntu под дерби?» — да абсолютно так же, как под обычное expressjs приложение, использующее mongodb и redis. Вообще нет отличий.
Дерби не пытается занять место целой экосистемы с деплоем, облаком приложений, своей системой модулей, репозиторием и т.д. И это просто офигенно. Именно это мне и нравится в дерби. Мне нужно запускать задачи по расписанию — я использую npm-модуль «cron» (он мне понравился больше других), нужно рассылать почту, беру node-mailer, хочу предварительно сжимать картинки/что-то делать с css и т.д — у меня есть grunt, gulp и т.д. Понимаете? Такая архитектура позволяет мне использовать все, что есть в nodejs экосистеме.
И недостатки здесь те же, что и вообще у ноды. Ну нет еще нормального модуля для деплоя под ноду. Мы сами в своих проектах для этого используем capistrano… Да — это так.
Так, пробегусть по пунктам, ответы на которые знаю:
CoffeeScript поддерживается из коробки, есть jade — альтернативный шаблонизатор вметсто handlebars (мы думали сначала о haml-е, но jade нам лично показался удобней, в итоге derby-jade). Для конфигов, мы лично исопjльзуем grunt-yaml, а потом nconf. Третий бутстрап добавляется одной строкой — из коробки есть less, но вы правы, я, например, не знаю о scaffolding-tool, которая бы в пару комманд развернула бы derby-приложение с предустановленным less-бутстрапом (по-моему в yeoman-е еще нет derby).
Бест-практики, как и документация в паблике — вы правы, отсутствуют. Мы у себя нарабатываем, созреем — поделимся. Ничего не могу сказать про миграции — просто не знаю, есть ли какие-то вообще инструменты на эту тему у монги (хотя вроде заканчивал курсы mongodb university по разработке, и там не было ничего такого), переводами тоже не занимался — не могу сказать.
Вообще, понятное дело. Кучу всего еще надо сделать, но для меня лично делема решена. Каждый, наверное, задает себе вопрос: а стоит ли то, чем я занимаюсь вложенных усилий. И мой ответ — да. Технология офигенна, и, вместо того, чтобы использовать вовсю нафаршированные технологии вчерашнего для, я лучше внесу свою лепту в derby, сделав его немножко лучше и ближе. В том числе и этими статьями.
unbindнадо писатьunbound{{unbind _page.value}}, либо, как в вашем случае, можно сделать необновляемым целый блок:А для того, чтобы в определенный момент все это перерисовать нужно использовать ключевое слово
on, то есть у вас будет примерно так:А при нажатии на кнопку что-то типа:
В «дерби-приложении», соответственно, ничего в
ctimeне пишите.(по поводу разделение клиента/сервера попозже напишу, после работы)
А потом можно через racer-access запретить доступ к коллекции users и пользователь сможет увидеть только то, что есть в users_small, обращаясь к ней как к обычной коллекции
Дерби не пытается занять место целой экосистемы с деплоем, облаком приложений, своей системой модулей, репозиторием и т.д. И это просто офигенно. Именно это мне и нравится в дерби. Мне нужно запускать задачи по расписанию — я использую npm-модуль «cron» (он мне понравился больше других), нужно рассылать почту, беру node-mailer, хочу предварительно сжимать картинки/что-то делать с css и т.д — у меня есть grunt, gulp и т.д. Понимаете? Такая архитектура позволяет мне использовать все, что есть в nodejs экосистеме.
И недостатки здесь те же, что и вообще у ноды. Ну нет еще нормального модуля для деплоя под ноду. Мы сами в своих проектах для этого используем capistrano… Да — это так.
Так, пробегусть по пунктам, ответы на которые знаю:
CoffeeScript поддерживается из коробки, есть jade — альтернативный шаблонизатор вметсто handlebars (мы думали сначала о haml-е, но jade нам лично показался удобней, в итоге derby-jade). Для конфигов, мы лично исопjльзуем grunt-yaml, а потом nconf. Третий бутстрап добавляется одной строкой — из коробки есть less, но вы правы, я, например, не знаю о scaffolding-tool, которая бы в пару комманд развернула бы derby-приложение с предустановленным less-бутстрапом (по-моему в yeoman-е еще нет derby).
Бест-практики, как и документация в паблике — вы правы, отсутствуют. Мы у себя нарабатываем, созреем — поделимся. Ничего не могу сказать про миграции — просто не знаю, есть ли какие-то вообще инструменты на эту тему у монги (хотя вроде заканчивал курсы mongodb university по разработке, и там не было ничего такого), переводами тоже не занимался — не могу сказать.
Вообще, понятное дело. Кучу всего еще надо сделать, но для меня лично делема решена. Каждый, наверное, задает себе вопрос: а стоит ли то, чем я занимаюсь вложенных усилий. И мой ответ — да. Технология офигенна, и, вместо того, чтобы использовать вовсю нафаршированные технологии вчерашнего для, я лучше внесу свою лепту в derby, сделав его немножко лучше и ближе. В том числе и этими статьями.
Может кому-то будет интересно.