> код, который и определяет, в какую версию кода приложения нужно «перейти»
ну то есть именно слой, просто прямо внутри приложения?
> для уменьшения запросов версия структуры БД кэшируется
т.е. мало того, что эта хрень жрёт лишнее время исполнения, она ещё и не риал-тайм? так зачем она вообще нужна?
т.е. у вас в дополнение к фронт-ендам и БД, есть ещё один слой, отъедающий время и лишний запрос к БД за каждый запрос к серверу?
очень интересный у вас «high-load»
как программист на Ruby и CoffeeScript, я долго висел над вариантами опроса, после чего нажал «воздержаться».
этот опрос действительно скорее «вентиляторный», чем «нужен автору на практике проектирования DSL»
да, Widget здесь, пожалуй, будет лучшим решением для организации кода. можно будет легко выделить код получения списка постов в него, и сделать отдельный partial для их отображения. и сам этот виджет можно будет приделать в layout прямо в темплейте для Layout в таком виде:
я, к сожалению, не знаком с ASP.NET Web Forms, но примерно понял, что вы имели в виду.
нет, здесь имелся в виду сам по себе принцип наличия в приложении состояния или его отсутствия, т.е.:
на сервере у вас есть запрос -> обработка -> ответ. вам по сути не важно, что пользователь до этого делал, и от предыдущих действий, т.е. состояния, эта обработка не зависит. в браузере же всё наоборот: хоть URL (хешбенг или pushState) и меняется, и от этого наступают какие-то независимые действия, приходится учитывать предыдущие действия пользователя, т.к. в зависимости от них в DOM могли остаться какие-то элементы, виджеты и прочее
так или иначе, чему-то придётся компилировать CoffeeScript. недавно на PHP, Node и Python начали расти проекты-аналоги Assets Pipeline, который этой компиляцией занимается в rails, поэтому мы будем рады, если кто-то из разработчиков на этих языках откликнется и сделает пакеты под эти проекты. но всё равно, потребность в сервере от этого не пропадёт.
да и это не главное, в общем-то. Joosy был ориентирован на большие многостраничные сайты с тесным взаимодействием с сервером, и он вряд ли сильно поможет приложениям-одностраничкам, типа излюбленного всеми разработчиками фреймворков TODO-list'а.
если говорить о шаблонизаторах для Rich Internet Applications, большинство из них, использующих искуственный синтаксис (в отличие от ECO к примеру), генерируют JST-интерфейс: то есть каждый шаблон или паршиал — это JS-функция, на вход которой идут данные для рендеринга, а внутри она представляет из себя набор таких же, как в этой библиотеке, вызовов функций, которые создают либо DOM-элементы, либо строки, которые эти элементы представляют в HTML.
так что это именно инструмент для организации этих шаблонизаторов, а не шаблонизации самой по себе
поддерживаю. у самого Nexus S, версия с AMOLED. чёрный цвет не отличается от цвета выключенного экрана, к экрану вообще ни разу не было нареканий. прошивка стоковая.
см. Терри Пратчетт
да вы, батенька, эстет :)
ну то есть именно слой, просто прямо внутри приложения?
> для уменьшения запросов версия структуры БД кэшируется
т.е. мало того, что эта хрень жрёт лишнее время исполнения, она ещё и не риал-тайм? так зачем она вообще нужна?
очень интересный у вас «high-load»
этот опрос действительно скорее «вентиляторный», чем «нужен автору на практике проектирования DSL»
нет, здесь имелся в виду сам по себе принцип наличия в приложении состояния или его отсутствия, т.е.:
на сервере у вас есть запрос -> обработка -> ответ. вам по сути не важно, что пользователь до этого делал, и от предыдущих действий, т.е. состояния, эта обработка не зависит. в браузере же всё наоборот: хоть URL (хешбенг или pushState) и меняется, и от этого наступают какие-то независимые действия, приходится учитывать предыдущие действия пользователя, т.к. в зависимости от них в DOM могли остаться какие-то элементы, виджеты и прочее
на очереди продвинутые туториалы и скринкаст.
будем благодарны за фидбек ;)
да и это не главное, в общем-то. Joosy был ориентирован на большие многостраничные сайты с тесным взаимодействием с сервером, и он вряд ли сильно поможет приложениям-одностраничкам, типа излюбленного всеми разработчиками фреймворков TODO-list'а.
так что это именно инструмент для организации этих шаблонизаторов, а не шаблонизации самой по себе
echo «gem 'haml/slim'» >> Gemfile
bundle install