Я бы сказал что это не шиза, а умение думать на разных уровнях абстракции одновременно – ключевой навык для хорошего программиста, что давно подметил Спольски :-)
Скажем так, если переформулировать вопрос как «следует ли отказываться от Backbone если не будет использоваться Router?», то ответ однозначно нет. Router не такая большая часть Backbone, гораздо больше (и, имхо, гораздо полезнее) логика работы моделей, коллекций, и связывание view с данными через систему событий.
по поводу инициализации, здесь смотря что считать долгой. скажем, полсекунды мало для progress bar-a а ля gmail, но уже ощутимо для пользователя. Если всю инициализацию выполнять после ready, есть риск заметно замедлить инициализацию приложения. Но в общем, чтобы не холиварить — мне кажется, стоит указать в вашем тексте, или в комментариях к коду, что предполагается, что view будет определяться после document ready.
У jQuery Templates, на которые вы указали, кэширование есть, но оно не совсем из коробки. То есть насколько я понимаю, многократный вызов $('#comment').template() будет-таки каждый раз компилировать шаблон, так что нужно руками проверять перед его вызовом, есть ли шаблон в $.template, и если да, то возвращать его.
да, насчёт $(document).ready вы правы, но в вашем случае необходимо чтобы определение view находилось внутри ready, а в моём — создание экземпляра. Что мне показалось более логичным, по крайней мере, у нас в коде экземпляры вьюх создаются только внутри ready.
Про кэширование я имел ввиду, что в моём случае _.template будет выполняться три раза (для каждого шаблона) каждый раз при создании view (то есть вызове new Block(...)). Чтобы этого избежать, скомпилированную функцию-шаблон стоит где-нибудь сохранять.
Вчера как раз полдня ловили ошибку в ие, которую с вашим кодом теоретически тоже можно словить:
var Block = Backbone.View.extend({
templates: { // Шаблоны на разное состояние
"start": _.template($('#start').html()),
"success": _.template($('#success').html()),
"error": _.template($('#error').html())
},
В данном случае templates инициализируются при создании констуктора view, а не экземпляра. И нет гарантии, что в этот момент нужные элементы с шаблонами будут в DOM. Чтобы избежать этого, стоит вынести создание шаблонов в метод initialize, который вызывается каждый раз при создании экземпляра:
+1
Для node.js+socket.io есть очень симпатичная обвязка на coffeescript: zappa
Поигрался с ней на днях, писать несложные приложения — одно удовольствие. Например, прототип чата в 46 строк (включая шаблон и клиентский js).
В итоге я сам решил все ему объяснить. Рассказал о том, какой смысл я вкладываю в понятие «воспоминание», рассказал о том, как правильно их извлекать и записывать… И, о чудо, через 10 воспоминаний я уже не успевал записывать все, что ему приходило в голову, а через 30, он забрал клавиатуру и погрузился в процесс сам.
Повторите своё объяснение в видео на главной, сохраняя простой дружеский тон, без «копирайтерства».
А тем, кто не хочет даже смотреть видео (лень, трафик и т. д.) помогут разделы «зачем» и «как начать» с короткими текстами и ссылками на то же видео.
Помнится, в своё время были люди, которые продавали специальные листы для перепросмотра. Не знаю уж, как они были устроены, но, скорее всего, пользоваться ими было не так удобно, как «вспоминатором».
Правда, вряд ли идеи перепросмотра можно использовать для массовой рекламы сервиса: «…открывается пугающая картина — во всех своих бедах, несовершенствах, несчастьях, ошибках виноват только ты сам. Ты оказываешься лицом к лицу с самим собой, без посредников, без оценщиков, без командиров, авторитетов … — то есть без оправданий» ;-)
Вот только с плюшками, видимо, нужно быть осторожным. Как писал ppk, «There is no WebKit on Mobile» (http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html). Видимо, у нас ситуация с мобильными браузерами немного другая, но подозреваю, что если скорректировать таблицу, сравнивающую поддержку плюшек 10ю разными вебкитами (http://www.quirksmode.org/webkit.html), для российского рынка, она останется такой же печально пёстрой.
Вы используете xslt на стороне браузера в живых проектах и у вас никаких проблем с рендерингом не возникает?
Если да, то, имхо, было бы здорово написать об этом статью. Потому что техника очень привлекательна, но как-то плохо документирована — статей толковых нет, производители браузеров её особо не рекламируют и ходят мифы о том, что это некроссбраузерно и ненадёжно.
Мне, например, помешало, когда фф молча падал при попытке рендеринга. Методом исключения выяснилось, что ему не нравился тег <br/> в таблице стилей. Сам по себе баг не страшный, но после него осталось ощущение, что как-то с поддержкой xslt в браузерах всё странно…
blog.jetbrains.com/webide/2012/03/phpstorm-webstorm-4-0-eap-117-65/
У jQuery Templates, на которые вы указали, кэширование есть, но оно не совсем из коробки. То есть насколько я понимаю, многократный вызов $('#comment').template() будет-таки каждый раз компилировать шаблон, так что нужно руками проверять перед его вызовом, есть ли шаблон в $.template, и если да, то возвращать его.
Про кэширование я имел ввиду, что в моём случае _.template будет выполняться три раза (для каждого шаблона) каждый раз при создании view (то есть вызове new Block(...)). Чтобы этого избежать, скомпилированную функцию-шаблон стоит где-нибудь сохранять.
var Block = Backbone.View.extend({
templates: { // Шаблоны на разное состояние
"start": _.template($('#start').html()),
"success": _.template($('#success').html()),
"error": _.template($('#error').html())
},
В данном случае templates инициализируются при создании констуктора view, а не экземпляра. И нет гарантии, что в этот момент нужные элементы с шаблонами будут в DOM. Чтобы избежать этого, стоит вынести создание шаблонов в метод initialize, который вызывается каждый раз при создании экземпляра:
var Block = Backbone.View.extend({
initalize: {
this.templates = {
"start": _.template ($('#start').html()),
"success": _.template($('#success').html()),
"error": _.template($('#error').html())
}
},
По-хорошему, конечно, нужно добавить кэширование, чтобы шаблоны не компилировались каждый раз.
Ben Cherry http://www.adequatelygood.com/
Rebecca Murphey http://blog.rebeccamurphey.com/
Eric Hynds http://www.erichynds.com/
И бесплатная книга по паттернам в JS (не такая фундаментальная, как книга Стефанова, но на определенном уровне может быть полезной).
Для node.js+socket.io есть очень симпатичная обвязка на coffeescript: zappa
Поигрался с ней на днях, писать несложные приложения — одно удовольствие. Например, прототип чата в 46 строк (включая шаблон и клиентский js).
Подробнее
Повторите своё объяснение в видео на главной, сохраняя простой дружеский тон, без «копирайтерства».
А тем, кто не хочет даже смотреть видео (лень, трафик и т. д.) помогут разделы «зачем» и «как начать» с короткими текстами и ссылками на то же видео.
Помнится, в своё время были люди, которые продавали специальные листы для перепросмотра. Не знаю уж, как они были устроены, но, скорее всего, пользоваться ими было не так удобно, как «вспоминатором».
Правда, вряд ли идеи перепросмотра можно использовать для массовой рекламы сервиса: «…открывается пугающая картина — во всех своих бедах, несовершенствах, несчастьях, ошибках виноват только ты сам. Ты оказываешься лицом к лицу с самим собой, без посредников, без оценщиков, без командиров, авторитетов … — то есть без оправданий» ;-)
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABoAAAAsCAYAAAB7aah%2BAAAASklEQVRYR%2B3N
uw2AMAxFUafgk7AA%2By9qUgTJYgGaU1y5sPROy8w7Is5Vn43SVe63%2Bn%2FrZeuY7autgUAgEAgEAoFAIB
AIBAKB%2FoYekNCvfRR1APoAAAAASUVORK5CYII%3D
минус 68 байт ;-)
а если уменьшить высоту с 24 до 10 пикселей:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABoAAAAKCAYAAACqnE5VAAAAM0lEQVQ4y2P8
%2F%2F
%2B%2FBAMDAwcUcwIxFxLmRqLRMbI8DHMimcUOxGxQzMo4atGoRaMWDR2LAOJ6J%2BOjg8yiAAAAAElFTkS
uQmCC
ещё минус 26 )
Если да, то, имхо, было бы здорово написать об этом статью. Потому что техника очень привлекательна, но как-то плохо документирована — статей толковых нет, производители браузеров её особо не рекламируют и ходят мифы о том, что это некроссбраузерно и ненадёжно.