【Java】Play framework【Scala】

Play frameworkを語る。

参考サイト
・本家( Java ) : http://www.playframework.org/
・本家( Scala ) : http://scala.playframework.org/
・日本語訳( Java ) : http://playdocja.appspot.com/
・日本語訳 ( Scala ) : http://playscalaja.appspot.com/

>>151
公式サイトにサーブレットで言うセッションとほぼ同等の使い方例示してあるよ
要はjsessionidの代わりとなるキーがありゃいいだけじゃん

>>149のように根本的に勘違いしてる人もいるようだが
わざわざSessionと言う用語を再定義してややこしくしたplay側にも問題はあると思う
わざわざSessionとかいうクラス名にせず最初から素直にCookieクラスにしときゃ誤解も生まれずわかりやすかったんじゃないの
そうすりゃ従来のSessionはCacheが肩代わりしますって話だけで済んだはず

>>151
結局、サーバー側で、安全にデータを保持する仕組みはないってことか。

>>153
暗号化してCookieに書き込んでいるだけのものをSessionと名づけたのは、
Playに機能がないことをごまかすためにわざと判りにくい名前にしたんじゃないか

とりあえず、>>143に対する回答としては「そういうときはCache使え」でFA
公式サイトもそう言ってるし、>>140のリンク先の人もはっきりとそう書いてる

公式サイト一通り読んだらこの辺のことは書いてあるんだから、やっぱりよくわかってない人だけがなんやかんやと騒いでるだけなんだろうな
それとも日本語訳のページからはこのあたりの情報が丸ごと抜けてたりするのか？

>>154
だからあるってば

>>154
俺の文の後半部分読んでる？
サーブレットでいうSessionはPlayではCacheと呼ばれる機能が肩代わりするんだと書いただろ
セッションIDのかわりにuuid発行する機能もある
これらを組み合わせてSessionと同等のことが一通りできる
日本語でも説明ちゃんとあったぞ
http://playdocja.appspot.com/documentation/1.1/cache

>>157
URL張るなら最新版はったほうがわかりやすいよ
1.1とか古いのもう新規で使わないでしょ

>>157
Cacheは消えてしまうから、保持できてるとはいえないないでしょ
設定した期限まで保持できないと同等とはいえない

複数サーバの場合も同一のデータを返す仕組みもない

データベース上にセッションの情報を保持する仕組みもない。

こっちにも書いてあるじゃないか
lifetimeを通じてデータを保持できるJava EEとは違うと書いてあるだろ？
キャッシュはあくまでもパフォーマンス改善のための仕組みでしかない。

Memcachedなんかもセキュアでないことも知ってるよな？


http://www.playframework.org/documentation/2.0.1/JavaCache

For any data stored in the cache, a regeneration strategy needs
to be put in place in case the data goes missing. This philosophy
is one of the fundamentals behind Play, and is different from Java
EE, where the session is expected to retain values throughout its lifetime.

似たような物はあれどいつ消えるかわかりませんよか

Memcachedがセキュアじゃないのは知らなかったな、同期のための通信が暗号化されてないとか？

ぐぐったら出るだろうと思ったらすぐ出た

Memcached に潜むセキュリティホール | スラッシュドット・ジャパン セキュリティ
http://security.slashdot.jp/story/10/08/10/0052240/Memcached-%E3%81%AB%E6%BD%9C%E3%82%80%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%83%9B%E3%83%BC%E3%83%AB

Cacheで同じような事はできるがステートレスを謳ってるんたから推奨はしてないだろうな。
あとSession(Cookieに保持する文字列)は暗号化じゃなくて改ざんチェックをしてるんじゃなかったかな？暗号化する方法も提供されてたとは思うが。

おいおい、PHPですらSessionあるのにPlayにはねーのかよｗ
「CacheがSessionの代わりになるんだよ(ｷﾘｯ」じゃねーよｗ
CacheはCacheだろ。Sessionじゃねーんだよ。
素直にPlayにはSessionありませんって言えばいいのに。
AP鯖も自作してんだからSessionぐらい実装しとけよな。
マジで使えねー。

もっとplayのだめなところを教えておくれ

>>163
分散機能のないPHP標準のセッションとごっちゃにするな恥ずかしい

>>1
Java用Webアプリケーションフレームワークの総合スレ立てた

【Java】 Java Web Application Framework 総合
http://toro.2ch.net/test/read.cgi/tech/1338707919/

>>165
でもPlayにはセッション自体がねーんだろ？
PHPにも劣るじゃん。

だからMemcachedだって

>>161
＞Web サーバー? memcached 間のネットワークをモニタすることで
こんなことされるような環境にしなきゃいいだけのこと

memcachedのこれがセキュリティホールなら、
セッションファイル開いたら中身まんま見れちゃうPHPも十分セキュリティホールだな

しかしcacheは保存の保証がないのが痛い

保証がないもんだと思って作ればいいんだろうが

PlayでSessionないのは
Seasarがホットデプロイで悩んでいた問題を解決するためだろうね。

セッションレプリケーションをなくしたいのなら
代替手段にデータベースもってくるはずだし。

2.0にメール機能は付くんかな

1.* にしか対応していないモジュールは待ってれば 2.0 にも対応しますかね。
oauth とか 2.0 で使えるとよいのになーと思っているのですが。

2,0 は標準の Play の API に OAuth とか OpenID 用のパッケージが入ってる。

Apache2にSSLの設定して連携する時って
Play Frameworkのアプリ側で必要な設定ってあるのでしょうか？

ttp://playdocja.appspot.com/documentation/1.2.3/production#server
SSLの設定はここを参考にしました。

>>175
ここよりは日本のユーザグループに質問投げた方がいいと思うよ。

>>177
やっぱりあっちのがいいかなぁ。
スタックオーバーフローは日本語がまるで見当たらなかったのでビビって逃げました。

検索してみても、同じ悩みの人がいるかもわからなかったorz

スタックオーバーフローなんて、日本語で書いている人誰もいないでしょ
@IT が、スタックオーバーフローと同じようなQAサイトを作ったので、そっちで聞いてみたら？
http://qa.atmarkit.co.jp/

いっぱい質問を登録してくれって中の人が言っていた。

>>179
そこ利用してみます、ありがとうです。

DotCloud + Play Framework1.2.3-1.2.5 アクションチェーンでhttpsからhttpに移動してしまう。 - QA@IT
ttp://qa.atmarkit.co.jp/q/2275

QA@ITに登録してみました。
こちらで回答いただけたらあたらにも反映しようと思うので、
こちらでも引き続き回答募集中です。

>>181
twitter #play_ja で特定したww
#play_ja は見ている人も多いから、きっと誰か反応してくれると思うよ。
回答があるといいね。

威勢がいいけど、アスミン一人で圧倒できるような

play 2.0.1 から触りはじめたけどいいね！
コードの量が少ない少ない。
驚いてる。

>>181
何気にplayの初質問なんだなｗ
rubyとrailsの質問が多い

「さよなら原発10万人集会」を新聞はどう報道したのか？検証してみた

★政府が隠蔽したいこと
↓
�@「坂本龍一　パブコメで声あげよう」
�A広瀬隆が原発の再稼働を止めるために電力会社と取引を計画
http://b●log.goo.ne.jp/yqmcps

歌＆作曲＆演奏：坂本龍一
http://www.youtube.com/watch?v=w22IhMuwhLw
http://www.youtube.com/watch?v=iVTFeozHWcA

Playの作者がScalaの会社から金を受け取るようになった2.0からアホになってるな。
2.0の戻り値でokとかnotFoundとかHTTPステータスを意識させるのは改悪というかアホだろ。
ok以外は必要なときに指定できればいい。どんだけ低レベル層のフレームワーク作る気だ。

フレームワークはアホ向きにあるもんだが、作るほうが理論優先で祖結合とか
頭でっかちになってくると、反転してアホになってることさえ気がつかないのか。
いや作者は分かってても、Scalaに金で買収されたから逆らえない罠。
金儲けが悪いとは言わない。ただ2.0はJava EEの匂いがする。

アホフレームワーク Play

2.0 系で servlet でいう setAttribute("string",object)
みたいなことってどうやるの？

業務で使っている人、ウェブサーバは何を使ってますか？
サクラで専用サーバだとApacheが入ってるからApacheになるのか
それともまんま play framework ？

業務で使えるレベルじゃないだろ

業務で使えるレベルって具体的にどういうレベルだよっていう。

明日発売のWeb+DBにplayframework2が載るね。

>>193
情報サンクス
Web+DBプレスとSoftwreDesign、
年購入しているものの2年間ぐらい積ん読しているままだが、
見てみよう

>>190
nginx使ってる
apacheやnginxのモジュール使う必要なければ素で受けてもいいと思う
って言ってもvirtual host切りたくなったりする場合が多いと思うけど

redisプラグインのソースがヒドイ。これ偶然キャッシュできるようになってるけど。
ifの条件が
value.getClass.isInstanceOf[String]
っていうコードの連発。書いたやつは死刑でいいよ。

>>197
ttps://github.com/typesafehub/play-plugins/blob/master/redis/src/main/scala/com/typesafe/plugin/RedisPlugin.scala
条件が常にfalse・・・
型チェックで分岐するのに
else if(){...}
else if(){...}
のelse if 連鎖で書かれていて、value.getClass.isInstanceOf[A]
ってチェックになっとる。Class型がSerializableだから
valueの型がなんであれ、Serializableのチェックに引っかかって動いているだけだな。
まさに偶然動作しているだけ・・・
しかしSerializableじゃない型がきてもSerializableと判断されてしまうのでアウトだな。
しかも最初のifチェックがSerializableのチェックだから、
仮にvalue.isInstanceOf[A]と正しく書かれていても
結局他の型チェックには回らないという無意味さ。

そのクソコード書いたのって、Playの開発リーダーじゃないの？

文句あるなら使わないかpull requestでも送ればいい

自分は気に入ってるけど、いまいち流行っている感じがないね。いいと思うんだけどなあ。

今1.2.5を使っているのですが、jobで非同期処理を組み込んだコントローラの機能テストって、バグってませんかね、、、
コントローラ内のawaitで結果を待つはずが、結果を待たずにそのまま突っ切っているような振る舞いでテストに失敗します。。。
実際の動作はきちんとawaitできているっぽいのですが、私のテストの仕方が悪いのでしょうか。
非同期jobを組み込んだ機能テストのやり方、設定などありましたら、おしえて下さい。

ORM の話です。java でebean の時、insertdate とか updatedate に @createtimestamp とか @virsion ってアノテーションつけたときのようなことを、scala で slick だとどうやりますか？ java だと、insert、updateの時、日時指定しなくても思った通りの値が入ってくれる。

heroku & eclipse
http://epubjpnet.herokuapp.com/toc/52badcf7td3bft4fe6t844ft1f0e61f31b4f/

>>196
これ素直に解決するのは無理なのかなあ

Play!2系のユーザーで、ScalaとJavaユーザーの比率はどれくらいなんだろう？

iterateeを自由自在に使いこなしてる人いる？
jettyの代替にplayを触り出したんだけど
脳みそがよじれそうorz

iterateeを乗り越え
slickを乗り越え
play jsonを乗り越え
やっとこさアプリができたけど
playのjsonってgsonと比べてパフォーマンスどうなの？

今度ベンチとってみるかなぁ

>>190
業務で使ってるけど
nginxをリバースプロキシにして一部のサービスだけをplayに投げてる

gzip圧縮とかが便利だから、APサーバの手前（同じサーバでもいい）にNginxかApache置くのが一般的

普通はバーチャルホスト使うだろうから結局フロントサーバは必要だしね

なんか本がでるらしい

Play Framework 2徹底入門
ttp://www.amazon.co.jp/dp/4798133922/

本楽しみなんだけどドキュメント充実してるし
買うほどの内容が無いんじゃないかと不安ドキドキ

しょうだつやの氏の本だから、 >>213 のとおり。

限界まで底が浅そうな本
どう考えても公式ドキュメントにも満たない量だろう

公式サイトの日本語訳プロジェクト、翻訳者はいたっぽいけど
マージできるレビュワーが放置しまくってるっぽくてなんか止まってる感じが惜しいな
日本は英語アレルギー多すぎるし、日本語情報が増えないと国内利用が増えないから仕事につながらないんだよなぁ…

ここ見てると散々な言われようだな
Scala自体はよくても、フレームワークがイマイチだと結局使えない

playは、評判悪いのか。
RESTfulな思想と合致するフレームワークかと思ったがボロクソ言われてるな。
StrutsでRESTは嫌だったからいろいろ探しているけれど、JAX-RS系のフレームワークの方が潰しがきくかな。

自分の周りではそこまで悪評は聞いてないな
ただいかんせん日本語情報は多くないから、英語アレルギーだと触ることすらできないって感じがするわ

いろいろクセがありすぎるけど、1.x系のPlayはとりあえず楽に書けるって点では嫌いではないよ
Resultの例外とかModelにLombokみたいなことやったりするあのあたりは面白い試みだと思う

Play1系はわからないが、Play2はわりと使えると思う。
個人的にはEBeanが採用されてデータベースまわりのストレスがないのが嬉しい。

ただ>>219も言ってるけど、日本語情報少なすぎて敷居が高いな。
行き詰まったときは英語圏のドキュメント探さないといけなくてかなり面倒だったし。
Java系としては生産性が高そうな気がするけどね

さっきTwitterのRTで知ったんだが、公式日本語ドキュメントきたみたい。
http://playframework.com/documentation/ja/

2.3系のドキュメント追加が待ち遠しい。

日本人のplay人口自体多くはないと思うけど、このスレはからっきしだな。
海外系以外だと、普段どういうとこで情報集めしてる？
Twitterとか見るのがいいのかな。

つか今更だけど2chはなんかもう新しいめの技術系のスレ、オワコンな感じするなぁ。どこも閑古鳥。

ルーティングいちいち定義すんのがくっそ面倒なんだけど
Controllerクラス名/アクション名を自動でパスにしたりできんの？
設定より規約でしょ？

2.3.3使ってるけどコンパイルが不安定だな
時々意味わからん失敗して、クリーンしたりすると成功したり。

SAStrutsのルーティング、糞みたいなクラス名にするか、くそみたいなURLにするかで
いつもイライラしっぱなしだった自分としては、ルーティングは設定ファイルのほうが好きだな

先に気持ちのいいURLを設計して、それに合わせて必要な単位でコントローラーのスタブを作る、って感じでやってる

あと、設定と実装が分離されてると、複数のURLから同じクラスの同じメソッドを呼び出すような事ができて便利

おお、なるほど。

>>225
＞いつもイライラしっぱなしだった自分としては、ルーティングは設定ファイルのほうが好きだな
別に設定ファイルなのは構わんが、バックエンドで使うようなもんはURLなんてどうでもいいから自動にしてほしいんだが
symfonyの1系とかはその辺選べて凄い便利で楽だったのに

＞あと、設定と実装が分離されてると、複数のURLから同じクラスの同じメソッドを呼び出すような事ができて便利
要するに自動ルーティングと手動ルーティングどっちもできるフレームワーク触ったこと無いんだな

だな。
暗黙的にできる規約と、追加設定でURL書き換えができれば、十分だ。
コントロ−ラ/アクションを明示するのは、複数のURLに対応させたい場合「だけ」でよい。

バックエンドにplayってどうなん
そういう環境でplayを選ぶメリットあんの？

は？
フロントエンドとバックエンドでいちいち分けて開発する方が今時無駄だろ

routesが別になってるのって、メソッドの指定とか自動設定じゃ難しそうな奴に対応するために仕方ないんじゃね。
自動設定だと、GETとPOSTを一緒くたに受け取る、とかになっちゃうし。

それに、コードを書くタイミングだと、アクション側からどう受け取るか書けたほうが楽だけど、
保守って観点でみると、routesだけ見ればURL全部把握できるし、予期しない入り口とかができなくてすむ。
コントローラーって別にURLから呼び出される公開メソッドしか定義しないものでもないし。

(個人的には)記述方法も複雑じゃなく読みやすく、良い感じのバランスじゃないかなぁ。
routesファイルがURL設計書の代わりみたいな感じ。

Ebean って無くなるの？

>>232
PHPのFWでみたことあるけど
getHogeやpostFugaみたいにHTTPメソッドの名前を頭につけるという規約を採用しているケース

routes.java:16: エラー: パッケージcontrollres.refは存在しません
とかいうエラーが出るんですけど、これ、何ですか？

リバースルーティング？
バグ？かこれ？

ナニコレ？勝手にリバースルーティングになる・・・。

何がしたいのかわからん

これって非標準でSpringみたいな位置づけのフレームワークだよな
ドメインモデル貧血症の解決を図ってるあたり気になる

EBean、Java8対応はされましたか？

Play frameworkで一番よい書籍はどれですかね

Play2.3.xでOSS作ってる者ですが、パーセントエンコーディングされたリクエストのcharsetがUTF-8決め打ちで処理されるので困ってます。色々と調べたのですが、UTF-8で処理する旨がコード中にハードコーディングされている[1]ため、ビルドし直さなければいけないようです。
せめて設定で書き換えられたら良いのにと思っていますが、どうやらUTF-8で全部通させるのがずっと方針[2]のようですね。
エンコーディング周りで苦労してる人はいますか？

[1] https://github.com/playframework/playframework/blob/master/framework/src/play/src/main/scala/play/api/mvc/ContentTypes.scala の tolerantFormUrlEncodedに"utf-8"とハードコーディングされている

[2] https://www.playframework.com/documentation/ja/1.2.x/i18n#utf8

>>241
正直StackOverflowと公式が一番役に立ってます。よくできた本はまだ見たことない感じです。
有志でWikiを作ったりして情報を集めたいですね。

>>242
OSS作ってるなら設定で書き換えられるようにプルリク作って投げればいいと思うけど、
世の中の流れ的にURLエンコーディングをUTF-8以外でっていうのはちょっとどうかと思うので、
むしろUTF-8じゃないそっちを説得すべきな気はします。
どこがUTF-8じゃないのかを教えていただければ変更願いだすのぐらいは手伝いますよ？

こんばんは。
初心者質問で申し訳ないのですが、playにはrailsにあるように管理画面を自動作成できるようなプラグインはありますでしょうか？

☆ 日本の核ブ装は絶対に必須ですわ。☆
http://www.soumu.go.jp/senkyo/kokumin_touhyou/index.html

☆ 日本国民の皆様方、2016年7月の『第２４回 参議院選挙』で、改憲の参議院議員が
3分の2以上を超えると日本国憲法の改正です。皆様方、必ず投票に自ら足を運んでください。
私たちの日本国憲法を絶対に改正しましょう。☆

ソース更新時に走るビルドが遅すぎて苦痛だわこれ

ReactとPlayの相性ってどうなんですかね？

なんだよ相性って
そんなもん勝手に組み合わせて使うだけのことだろ
一体どうなると相性が悪くてどうだと相性がいいんだよｗ

playframework完全に下火だな、、spring bootとどっちにするか迷ってたが、
危うくplayの誇大広告に騙されるとこだった
お前らも気をつけろよ
https://trends.google.co.jp/trends/explore?date=all&;q=play%20framework

誰でも簡単にネットで稼げる方法など
参考までに、
⇒　『半藤のブブイウイウレレ』 というサイトで見ることができます。

グーグル検索⇒『半藤のブブイウイウレレ』

K0XR52IV2N

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

デザインパターンをインターフェースから説明した良心的なブログ
途中で息切れしてるみたい？？

https://blogs.yahoo.co.jp/kamyu_2010/35417803.html