Комментарии 38
за допиливание туториала — огромное спасибо.
Интерестный подход. Правда очень огорчило что нужно держать сервер для этого дела.
Просто запустить приложение на клиенте не получится :(
Просто запустить приложение на клиенте не получится :(
так или иначе, чему-то придётся компилировать CoffeeScript. недавно на PHP, Node и Python начали расти проекты-аналоги Assets Pipeline, который этой компиляцией занимается в rails, поэтому мы будем рады, если кто-то из разработчиков на этих языках откликнется и сделает пакеты под эти проекты. но всё равно, потребность в сервере от этого не пропадёт.
да и это не главное, в общем-то. Joosy был ориентирован на большие многостраничные сайты с тесным взаимодействием с сервером, и он вряд ли сильно поможет приложениям-одностраничкам, типа излюбленного всеми разработчиками фреймворков TODO-list'а.
да и это не главное, в общем-то. Joosy был ориентирован на большие многостраничные сайты с тесным взаимодействием с сервером, и он вряд ли сильно поможет приложениям-одностраничкам, типа излюбленного всеми разработчиками фреймворков TODO-list'а.
так или иначе, чему-то придётся компилировать CoffeeScriptВообще говоря, есть coffee-script.js, который транслирует CoffeeScript в JS прямо на клиенте. Хотя, конечно, при большом количестве кода это будет подтормаживать.
> stateful
А это у вас на ASP.NET Web Forms не похоже?
А это у вас на ASP.NET Web Forms не похоже?
я, к сожалению, не знаком с ASP.NET Web Forms, но примерно понял, что вы имели в виду.
нет, здесь имелся в виду сам по себе принцип наличия в приложении состояния или его отсутствия, т.е.:
на сервере у вас есть запрос -> обработка -> ответ. вам по сути не важно, что пользователь до этого делал, и от предыдущих действий, т.е. состояния, эта обработка не зависит. в браузере же всё наоборот: хоть URL (хешбенг или pushState) и меняется, и от этого наступают какие-то независимые действия, приходится учитывать предыдущие действия пользователя, т.к. в зависимости от них в DOM могли остаться какие-то элементы, виджеты и прочее
нет, здесь имелся в виду сам по себе принцип наличия в приложении состояния или его отсутствия, т.е.:
на сервере у вас есть запрос -> обработка -> ответ. вам по сути не важно, что пользователь до этого делал, и от предыдущих действий, т.е. состояния, эта обработка не зависит. в браузере же всё наоборот: хоть URL (хешбенг или pushState) и меняется, и от этого наступают какие-то независимые действия, приходится учитывать предыдущие действия пользователя, т.к. в зависимости от них в DOM могли остаться какие-то элементы, виджеты и прочее
Нет, не похоже. Тот факт, что у форм если скрытое поле с дампом ядра переменных, не делает веб-приложение stateful.
Ребят, не поверите, но я, похоже, экстрасенс.
Сегодня вечерком наткнулся на Joosy, бороздя гитхаб. Зашел на сайт, читнул гайд — заинтересовало. Рассказал коллегам. Часа два назад сел реализовать микро-проект. Собственно, для него я и ходил по гитхабу, обыскивая решения с backbone или ember.js, взвешивал что и как, ибо хотелось попробовать что нибудь отличное от Backbone, есть неудобные моменты, а тут Joosy. В общем, сделал я что хотел, не потратив времени на бутстреп рельсового проекта и прочего, и прочего. Красота, в общем.
Но возник у меня вопрос. Для примера возьму разработку блога из гайда. Собственно, вопрос: подскажите, пожалуйста, best practice для того, чтобы, скажем, был некоторый виджет(?) со списком всех постов на уровне лэйаута, то бишь, существующий на всех страницах, другими словами, некоторая глобальная навигация.
Пока писал, пришла в голову мысль, что я, похоже, что-то упустил в доках и мне нужны те самые «виджеты».
Сегодня вечерком наткнулся на Joosy, бороздя гитхаб. Зашел на сайт, читнул гайд — заинтересовало. Рассказал коллегам. Часа два назад сел реализовать микро-проект. Собственно, для него я и ходил по гитхабу, обыскивая решения с backbone или ember.js, взвешивал что и как, ибо хотелось попробовать что нибудь отличное от Backbone, есть неудобные моменты, а тут Joosy. В общем, сделал я что хотел, не потратив времени на бутстреп рельсового проекта и прочего, и прочего. Красота, в общем.
Но возник у меня вопрос. Для примера возьму разработку блога из гайда. Собственно, вопрос: подскажите, пожалуйста, best practice для того, чтобы, скажем, был некоторый виджет(?) со списком всех постов на уровне лэйаута, то бишь, существующий на всех страницах, другими словами, некоторая глобальная навигация.
Пока писал, пришла в голову мысль, что я, похоже, что-то упустил в доках и мне нужны те самые «виджеты».
да, Widget здесь, пожалуй, будет лучшим решением для организации кода. можно будет легко выделить код получения списка постов в него, и сделать отдельный partial для их отображения. и сам этот виджет можно будет приделать в layout прямо в темплейте для Layout в таком виде:
.posts
!= <hh user=widget> 'div', PostsListWidget
хабрапарсер съел @widget
Всё же, документация слабовата. Либо я слабоват на ночь глядя. Но если серьезно, не нашел ни в гайде, ни в api-документации. Так вот как бы мне рендерить этот виджет в момент, когда загрузятся данные?
Пора спать, да.
Пора спать, да.
Документация действительно не идеальна. Это проблема почти всех проектов, которые только пережили релиз :). Очень не хватает рук.
В момент когда рендерится ваш шаблон, данные уже загружены. Следовательно вы можете передавать в виджет все, что хотите. Но в этом конкретном случае я бы использовал другой способ работы с виджетами:
raw.github.com/gist/2828061/e9214ac84937c40daaa2da882b49cf6da939f8bd/Widgets%20Hash.coffee
Этот хэш отработает после загрузки, в нем, используя лямбду, вы можете передать в виджет какую угодно локальную переменную (примеры 1 и 3). Допустим коллекцию постов. А он уже в себе ее отрендерит.
Если все же, вы будете включать виджет прям в шаблоне, флоу будет следующим:
1. Вы загружаете нужную коллекцию и кладете ее, например, в data.posts
2. Она доступна в шаблоне. В шаблоне вы создаете виджет лямбдой: `=> new PostsListWidget(@posts)` вместо просто класса виджета.
3. Виджет получает данные в конструктор и может пробросить их к себе в шаблон.
4. ???
5. PROFIT! :)
В момент когда рендерится ваш шаблон, данные уже загружены. Следовательно вы можете передавать в виджет все, что хотите. Но в этом конкретном случае я бы использовал другой способ работы с виджетами:
raw.github.com/gist/2828061/e9214ac84937c40daaa2da882b49cf6da939f8bd/Widgets%20Hash.coffee
Этот хэш отработает после загрузки, в нем, используя лямбду, вы можете передать в виджет какую угодно локальную переменную (примеры 1 и 3). Допустим коллекцию постов. А он уже в себе ее отрендерит.
Если все же, вы будете включать виджет прям в шаблоне, флоу будет следующим:
1. Вы загружаете нужную коллекцию и кладете ее, например, в data.posts
2. Она доступна в шаблоне. В шаблоне вы создаете виджет лямбдой: `=> new PostsListWidget(@posts)` вместо просто класса виджета.
3. Виджет получает данные в конструктор и может пробросить их к себе в шаблон.
4. ???
5. PROFIT! :)
gist.github.com/2870880 — вот живой пример. Он набросан от руки, as-is вполне возможно не заработает. Но идея должна быть понятна :)
для таких я бы посоветовал прочитать пункт первый отсюда :)
Искать альтернативы, коих, много. Joosy не целится на 100% потребителей :). CoffeeScript – один из китов Joosy. По моему скромному мнению, та же самая структура, описанная на JS превращается в кашу. Поэтому к сожалению, это не изменится никогда.
Не хватает примеров кода прямо здесь, без необходимости щёлкать по ссылкам.
Я так не играю:
Подскажите, никак не могу понять, каким образом происходит монетизация в подобных проектах? Или никакой монетизации нет вовсе, и это держится на чистом энтузиазме?
Мои поздравления, Борис
Господа, а где можно посмотреть дейсвующие production приложения на joosy?
$('div.joosy_usage_module') # (ссылки в футере)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Joosy: альтернативный подход к браузерным фреймворкам