3

MySQLで動作するように構成されたPlay2.0.3を使用しています。すべて正常に動作しますが、問題は非常に単純です。ビューの1つ（単純なHTML要素でも）を変更するたびに、アプリをリロードしてテストするのに非常に時間がかかります。出力で、mysql接続が再構築されていることがわかります。これは出力です：

--- (RELOAD) ---

[info] play - database [default] connected at jdbc:mysql://localhost/test?useUni
code=yes&characterEncoding=UTF-8&connectionCollation=utf8_general_ci
[info] play - Application started (Dev)

これは非常にシンプルなアプリであることを忘れないでください。ちょうどそれを構築し始めました。単純なHTML/ビューの変更をすべてテストするには、5〜10秒かかります。

私はここで何かが欠けていますか？Play 2.0では複雑な時間が問題であることがわかりましたが、少なくともデータベース接続の再読み込みを回避するにはどうすればよいですか？

ありがとう、デビッド。

4

2 に答える 2

4

どういうわけか構成可能かどうかは疑問ですが、役立つヒントがいくつかあります。それらすべてを組み合わせるのが最善だと思います。

  1. 次のコマンドを使用して開発用のアプリを実行します。-play ~runファイルが変更された直後に、バックグラウンドで再コンパイルされます。再コンパイル時間を短縮することはできませんが、少なくとも煩わしさは少なくなります。
  2. 一度にもっと書いてみてください:)小さな変更をすべて閲覧して、「ああ、この詳細はまだ...ああ、この詳細はまだ... 」と考えるとき、再コンパイルに必要な時間は本当にひどいものになる可能性があります。代わりに、修正したいすべての詳細を確認して、変更を一度に挿入してください。レイアウトの詳細を修正するために1〜2分を費やす場合、5秒待つことはそれほどひどいことではありません。
  3. ブラウザーの検査ツールを使用して、出力HTMLをデバッグします。バグがどこにあるかを確認し、ビューに挿入せずに小さなコードの変更をテストできます。
  4. 多くのJS、CSSなどを含む非常に複雑なレイアウトがある場合は、Playでレンダリングされた出力を静的ファイルとして保存し、最初に必要に応じて機能させます。終了したら、静的HTMLの変更をビューに移動します。静的ファイルの変更のテストは、毎回再コンパイルする必要がないため、はるかに高速になります。
  5. gitを使用します（ローカルリポジトリとしてのみ使用する場合でも）。gitとIDEを組み合わせてサポートすることで、変更を加えた場所と、静的テストファイルからビューまたはアセットの最終バージョンに何を移動する必要があるかがわかります。
于 2012-08-13T12:09:55.403 に答える
0

これはバグのようです。再現性のある小さなテストケースを作成し、バグトラッカーで報告することをお勧めします： https ：//play.lighthouseapp.com/projects/82401-play-20/overview

于 2012-09-23T21:03:23.210 に答える