以前の回答を提供しましたが、この投稿の最後にまだあります。しかし、あなたのコメントから、それがどれほど危険であるかを理解せずに、他の何かを求めていることがわかります.
ユースケースを処理する方法は 3 つあります。最悪の方法から始めましょう。
ステートフル Web アプリケーション
何らかのデータ ソースから Pojo にデータをロードし、複数のリクエスト間で Pojo を再利用したい場合は、キャッシュなど、サーバーに何らかのクライアント状態を実装する必要があります。Web アプリケーションは長い間この方法で開発されてきましたが、これが大きなバグやエラーの原因でした。データベース内の基礎となるアカウント データが、1 つの HTTP リクエストと次のリクエストの間に更新されるとどうなりますか? キャッシュされたデータを使用するため、クライアントには表示されません。さらに、ユーザーがブラウザで戻るとどうなるでしょうか? ユーザーがナビゲーション フローのどこにいるかを追跡するために、サーバー側でどのように通知を受け取るのでしょうか? これらの理由やその他の理由から、Play! ステートレスになるように設計されています。Web アプリケーションに本当に興味がある場合は、おそらく REST アーキテクチャ スタイルとは何かについて読む必要があります。
ステートレス Web アプリケーション
ステートレス Web アプリケーションでは、2 つの HTTP リクエスト間でデータを保持することは許可されていないため、データを処理するには 2 つの方法があります。
ワンショットでユーザーインターフェースを生成
これは、アカウント データが減少した場合に使用できるアプローチです。各アカウントから必要なすべてのデータをページに埋め込み、ビューを生成します。ビューは非表示のままにし、ユーザーがクリックしたときにのみ表示します。サーバー側で HTML を生成し、JavaScript を使用して DOM の特定の部分のみを表示するか、アカウントの JSON 表現を転送し、何らかのテンプレート ライブラリを使用して必要な UI をクライアントで直接構築することができます。
必要に応じてユーザー インターフェイスを生成する
このアプローチは、アカウント データ構造に含まれる情報が多すぎて、クライアント上のすべてのアカウントのすべての情報を最初に転送したくない場合に必要になります。たとえば、ユーザーが非常に少数のアカウントの詳細のみを表示することに関心があることがわかっている場合は、ユーザーが要求したときにのみ詳細を要求する必要があります。
たとえば、アカウントのリストには、詳細と呼ばれる各アカウントに関連付けられたボタンがあり、アカウント ID を使用して新しい要求をサーバーに送信します。
@(accounts: models.domain.AccountList)
@titlebar = {<p>some html</p>}
@content = {
@for(account <- accounts) {
<p>@account.name <button class="details" href="@routes.Controllers.account(account.id)">details</button></p>
}
}
クライアント側でユーザー インターフェイスを生成することもできますが、ユーザーがボタンをクリックしたときにデータ構造をサーバーから取得する必要があることに注意してください。これにより、ユーザーはアカウントの最後の利用可能な状態を確実に取得できます。
古い答え
ビューを再利用することが目標である場合、Play ビューは Scala クラスに他ならないため、インポートすることができます。
@import packagename._
そして、それを別のテンプレートで使用します。
@for(account <- accounts) {
@account(account)
}