playframework 2, как добавить свой каталог для ассетов?

когда ты выбирал фреймворк, пожалуй важным пунктом было «гуглится/не гуглится», у плей с этим видимо плохо + тут как то не спешат помочь, даже анонимы не пишут =)

самое гуглящееся слово - «говно». И «порнуха». Наверное, нужно было писать на порнушном говне )))

гуглится хорошо. Но работает только на maintainance release. А у меня latest stable. Возмно стоит сразу попробовать самую голову гита, но рука не поворачивается (прошлый раз с этим было много гемора, а сейчас тонну говнокода нафигачить надо до понедельника - времени думать и разбираться просто нет, нужно рабочее решение).

Я вот отказался от использования ассетов. Вся статика живёт отдельно. На то была своя причина: на play 2.0 в дебажном режиме каждый ассет отдаётся неприлично долго. В итоге у меня отрисовка одной странички занимала не менее минуты. Дебажиться в таких условиях, естественно, невозможно. Не знаю как у плея с этим в текущих релизах.

У него ещё и документация очень скудная и зачастую устаревшая. В доке версии 2.2 встречаются куски, которые работали в 2.0, но в 2.2 в принципе работать не будут.

Я вот отказался от использования ассетов. Вся статика живёт отдельно.

ну какбе ассеты - это «динамика». Например, вместо CSS - LESS, вместо Javascript - Coffeescript. Кому-то всё равно это придется компилировать.

на play 2.0 в дебажном режиме каждый ассет отдаётся неприлично долго. В итоге у меня отрисовка одной странички занимала не менее минуты.

эээ никогда такого не было

может, у тебя комп послабее? У меня i7 2600K, 16 гигов оперативки, HDD WD Caviar Black с виндой и SSD Vertex3 с проектом.

на iMac'2012 i5, 8 гигов рамы и какой-то более медленный HDD - на глазок падение скорости сборки вполне имеется. Поэтому я стараюсь кодить не на нём, а на предыдущем конфиге.

или у меня проект поменьше.

или, например, ты пользовался Windows, и проект лежал на том же диске что и ОС. Тогда полный капут, винда сама постоянно пишет кэши со скоростью 4мб/с, плюс к этому реиндексация IDE (от 1 до 20 мб/с), плюс фоновый компилятор Scala в IDE, плюс к этому собственно вотчеры Play и sbt. Жесткий диск может не вывезти. Нужно обязательно переместить всё это на разные жесткие диски, а лучше сразу на SSD.

или ты правил ассеты с одновременной правкой фронт-контроллера. Там понятно, когда ты меняешь хоть что-то в имеющем состояние коде, релоадится сразу весь движок. Если ты там наговнокодил всяких объектов/синглтонов в которых что-то делается, или просто вклинился в старт и накодил там какого-то долгоработающего кода, этот код будет выполняться тысячу раз на каждый чих, возможно даже не один раз за рестарт.

С одной стороны, согласен.

С другой, смотря с чем сравнивать.

Сравни-ка с инфраструктурой Node.JS. Документация типично хипстерская, а IDE не может такой код анализировать.

Я перешел с Node.JS на Play и почувствовал прямо огромный порядковый рывок вперед в смысле производительности кодинга (и огромный порядковый рывок назад по количеству потребляемой RAM)

Например, вместо CSS - LESS, вместо Javascript - Coffeescript.

У нас этого добра нет. Первого по причине низкой квалификации верстальщика, второго - по причине нежелания разводить зоопарк. Но если бы пришлось делать сборку статики (а этот вопрос скоро назреет), то я просто запилю сборочные скрипты в проекте статики, не вижу никаких проблем.

эээ никогда такого не было

Нет, дело не в скорости работы компа. И не в перекомпиляции. По какой-то неведомой мне причине каждый запрос отрабатывал примерно по секунде, а то и дольше. У тебя версия play какая?

2.2.x, в режиме scala

после изменения ассета, который надо пересобирать, на каждый такой ассет тратится по секунде и больше. И намного больше секунды при изменениях, требующих перезапуск движка.

я просто использую 1 LESS-файл, в который импортом (встроенной возможностью LESS'а) добавляются все остальные стили. По сравнению с общим размером страницы, оверхед на дополнительные стили незначительный, плюс в продакшене это клиенту будет стоить 1 раз закэшировать файл, который вдобавок еще и gzip'нут, а вперспективе еще и можно положить под nginx.

А со стороны разработчика инклуды даже удобней, чем тыщи мелких css-файлов. Например, у меня первой строчкой подключается Twitter Bootstrap (его LESS-версия из гита, да), и потом IntelliJ IDEA прямо в редакторе кода делает автодополнение по бутстраповским стилям.

вообще да, это геморрой. Но на предыдущих технологиях (аппа с использованием фреймворка Wicket, например), на каждое изменение в классах приходилось вручную перезапускать весь сервер. А это больше минуты. Неважно, хоть Томкат, хоть встроенный Jetty. Поэтмоу то, что несчастный LESS-файл перезагружается пару секунд (да еще без моего участия) пока не очень напрягает.

Первого по причине низкой квалификации верстальщика

можно объяснить как «LESS - это такой CSS, где есть переменные». Самая мастхэвная фича. Например, есть у тебя какой-нибудь прибитый к низу окна футер размером 60 пикселей, и относительно него считаются все остальные вертикальные размеры. И вот, размеры футера поменялись. Верстальщику ооочень геморно сидеть и по часу-больше вылавливать все вхождения чиселок, основанных на исходных «60 пикселях» - сами «60 пикселей» еще можно find and reaplce, а вот зависящие от них величины - жопа. Вместо того, чтобы тратить дни на безмозглую работу по find and replace, проще потратить полчаса на чтение документации LESSа, один раз определить размер футера переменной и радоваться.

когда ничего не пересобирается, вызов «статики» медленней, чем в продакшене, но вполне приемлемый. Почти мгновенно.

Ну на 2.2 я не пробовал. Вроде они говорили, что все просадки производительности и внезапные падения в дебаге починили. Но возвращаться на ассеты теперь лениво.

возвращаться на ассеты

так там же разница вся только в том, в какой каталог ты их пихаешь? Файлы из каталога /public не собираются, файлы из каталога /assets собираются. Клиенту видны они по одному и тому же урлу, как будто это одна директория. В частности, если положить файл с одним и тем же именем в обе диретории (и паблик и ассетс), то будет жуткая ошибка.

Реверс-роутером можно не пользоваться, прописывать урлы вручную (ну шо, ты не запомнишь аж целый 1 урл, с которого начинаются все ресурсы?). Ладно бы еще можно было нафигачить разных директорий до разных ассетов, и была бы куча разных урлов, но проблема как раз в том, что эта фича не работает. А пользоваться реверс-роутером для запоминания аж 1 урла - это фича для склеротиков в терминальной стадии))

GET /assets/bootstrap-dist/*file controllers.Assets.at(path=«/app/bootstrap/dist», file)

Сразу после строки GET /assets/*file controllers.Assets.at(path=«/public», file)? Не работает, потому что запрос ловится первым маршрутом в файле.

реверс-роутер работает. Сообщение контроллеру отправляется.

но такого файла нет! нечего брать!

как заставить его собирать ассеты, лежащие не только в /assets, но и в других местах?

Не работает:

GET /assets/*file controllers.Assets.at(path=«/public», file)
GET /assets/bootstrap-dist/*file controllers.Assets.at(path=«/app/bootstrap/dist», file)

Работает:

GET /assets/bootstrap-dist/*file controllers.Assets.at(path=«/app/bootstrap/dist», file)
GET /assets/*file controllers.Assets.at(path=«/public», file)

Работает:

GET /assets/*file controllers.Assets.at(path=«/public», file)
GET /myassets/bootstrap-dist/*file controllers.Assets.at(path=«/app/bootstrap/dist», file)

но такого файла нет! нечего брать!

Проверил с play-2.2.1, файл лежит target/scala-2.10/classes/app/. Соответствующее задание в sbt называется copyResources, убедиться что оно работает нормально (по крайней мере на свежесозданном проекте) можно набрав в консоли set logLevel in Global := Level.Debug.

Официальная документация: http://www.playframework.com/documentation/2.2.x/AssetsLess, раздел Configuration, если я правильно понял проблему. Есть аналогичные ключи coffeescriptEntryPoints и javascriptEntryPoints.

А, нужны не managed assets, а просто assets. Тогда должно работать по рецепту анонимуса.