Pull to refresh

Comments 26

DSL с #{} показался мне не удобным, может я просто привык к рельсам.
Пожалуйста напишите одну из статей как завести Play на GAE + GWT
Спасибо! Выглядит довольно вкусно:) Всегда мечтал об удобном и гибком Ява-фреймворке! интересно бы сравнить его с Grails.

Извините за оффтопик, но неужели для friendly URL интернет не придумал ничего лучше чем ЧеловекоПонятный Урл? Настройка ЧПУ звучит как будто в цехе столярный станок настраиваешь.
Вопрос и возник из указанной страницы в википедии.

Я, конечно же не первый, кто сталкивается с жаргоном в интернете, просто нормальная статья на википедии про чистые URL, почему то озаглавлена жаргонным ЧПУ, а не скажем «Чистые URL» как здесь. Это и сбило с толку.
хм, не видел в статье на русском упоминания REST! наводит на мысли…
Пробовал.
* Часто обваливается без объяснения причин.
* Очень неуклюжей показалась система добавления собственных методов во вьюхи.
* Баг-фича — нет поддержки сессий (вернее она теоретически может быть и в то же время они позиционируют фреймворк как безсессионный)
* Вроде бы веб-фреймворк, а набор нужных функций меньше минимума. Допустим, чтобы конвертировать "><" в "<>" нужно подключать третью библиотеку, хотя функция для обратной конвертации есть в стандартном пакете.

В общем, копнул бы дальше, но после того, как в очередной раз сервак отвалился, надоело :)
в последнем пункте там &lt,&gt
Печально! Может в будущих релизах пофиксят. Grails ведь улучшался и улучшался…
1. Возможно используется нестабильная версия JVM.
2. Что вы имеете ввиду? Зачем во view добавлять методы? Или имеется ввиду использование методов при помощи конструкций ${}, #{}, @{} и &{}?
3. Поддержка сессий есть, см.: www.playframework.org/documentation/1.1/controllers#session
4. escapeHtml(), escapeJavaScript(), escapeXml(), raw(), nl2br() & etc. к вашим услугам.
Сессии есть но они сами там пишут «не используйте сессии, т.к. фреймворк сразу станет трудно масштабировать».

unescapeHtml() нужен был. В стандартном пакете нет, а чтобы докрутить надо писать свою функцию.
> Сессии есть но они сами там пишут «не используйте сессии, т.к. фреймворк сразу станет трудно масштабировать»

И правильно пишут, сессии не для хранения данных (максимум, для хранения user_id и тому подобной мелочи). А ещё, «The Play session is not aimed to be used as a cache». Подробнее: www.playframework.org/documentation/1.1/cache#session

> unescapeHtml() нужен был. В стандартном пакете нет, а чтобы докрутить надо писать свою функцию.

Честно говоря не могу придумать ситуации, когда он необходим в правильно построенном Web-приложении.
— Я и не использую сессии для хранения данных =) Я использую сессии, чтобы не авторизовывать и не аутентифицировать пользователя при каждом малейшем запросе.

— Ну предположим, нужно взять из базы кусочек html, нарисовать его на странице и рядом вывести его исходник.

— Ну, скажем не совсем так, они пишут на главной, что фреймворк «Stateless» (то есть это как бы его фишка). А в доках было написано, что мол… нуу… сессию можно организовать, но там проблемы возникнут, когда серверов много и т.д. В общем-то, стандартная проблема — где хранить инфу о сессиях.
> Сессии есть но они сами там пишут «не используйте сессии, т.к. фреймворк сразу станет трудно масштабировать».

А где они такое пишут?
Фреймфорк супер, как раз ковыряюсь в говнище REST сервисов, и Play тут как нельзя кстати. После Spring MVC и его аннотаций такое облегчение, словами не передать. Ну и похожесть на рельсы интересу добавляет, хочу однажды руби всерьез попробовать.

Вот только у них синтаксис для if-else в темплейтах забавный, я думал что нибуть новое тут придумать сложно, но они расширили мне сознание

#{if flash.error}
	<p style="color:red">
		${flash.error}
	</p>
#{/if} #{else}
	<p>
		Hello ${name ?: 'guest' }!
	</p>
#{/else}


С энтузиазмом ковыряюсь дальше в поисках открытий.

Большое человеческое спасибо за понятный обзор!
А чем аннотации в MVC 3 версии не ОК?
Ну как минимум тем что их требуется больше и они захламляют сигнатуру методов контроллера, в Play их требуется меньше и они короче.

Кроме того не требуется никаких дополнительных манипуляций с фреймворком, в Spring же требуется как минимум отконфигурировать скан компонентов.
Зато радует возможность писать такие конструкции (делать что-то, если список пустой):

#{list items:task, as:'task'}
  ${task}
#{/li}
#{else}
  Nothing to do…
#{/else}
Небольшое сравнение производительности Spring MVC vs Play. Тестировалася отдача простой странички с формой (не бизнес-логика), то есть по сути дает представление о скорости выдачи горячего динамического контента

mvn tomcat:run (spring-mvc)

Requests per second:    8619.68 [#/sec] (mean)
Time per request:       1.160 [ms] (mean)
Time per request:       0.116 [ms] (mean, across all concurrent requests)

play (prod)

Requests per second:    2742.93 [#/sec] (mean)
Time per request:       3.646 [ms] (mean)
Time per request:       0.365 [ms] (mean, across all concurrent requests)

play (dev)

Requests per second:    521.27 [#/sec] (mean)
Time per request:       19.184 [ms] (mean)
Time per request:       1.918 [ms] (mean, across all concurrent requests)
Фреймворк выглядит обещающе. Наконец-то в мире java веба появилось что-то, с чем не надо возиться полчаса, только чтобы поднять простейшее приложение. Но все-таки зря они сделали в контроллере все методы static. Я в курсе, что у них есть @Inject аннотация, чтобы делать IoC, но все равно не true это, имхо.
Не согласен — как раз true, контролер не должен хранить состояние так что делать методы статиками — вполне нормальная практика, а вот то что действие не возвращает значения больше запутывает чем привносит ясности.
Быть static и не хранить состояние — это не одно и тоже. Да, про возвращаемое значение верно замечено, смущает сильно.
То, что нет возвращаемого значения у action, после Ruby on Rails вполне привычно и ожидаемо.
Вообще очень хороший фреймворк. Достойная замена C# в Linux и Mac OS.
Sign up to leave a comment.

Articles