無しで、オンメモリで疑似的なものです。性能も当然(?)意識していません。考察のスタート地点としてlombokなど使わずに、ベタで実装したものです。考察のための入り口なので、これがJSFの普通の実装では確実にありません。過去に考えた、以下をベースに作成しています。vermeer.hatenablog.jpvermeer.hatenablog.jpそれ以外の詳細で、見直したところだけを以下に追記します。まとめれば良いだろう、と思っていました。わかりにくく感じました。個々の部品は別パッケージにしました。悩んだのは、画面ルートとなるForm内で繰り返しの要素として使用するFormです。部品と言えば部品ですが、集約と言えば集約です。考え直す可能性があります。xhtmlは会話スコープブラウザから参照するxhtmlは同一会話スコープとなるものを同じフォルダで管理します。いっても、今回はConversationScopedではなくSessionScopedを使って手抜きをしています。後日リファクタリングするつもりです。いう感じで資産を管理するのか、ということを整理するに留めます。JSFの基本的な作りに近しい感じにしました。各ページの具体的なコンテンツはWEB-INF配下に整理します。実装xhtmlをEEサーバーを介さず、直接ブラウザで閲覧しても問題なくデザインを確認できるようにしています。なるかな?と思います。それは仕方ないかな、と。そのまま使えるというのは良いですね。Actionvalidationもしていません。例外がスローされます。今回は、あくまで実装の流れを整理する事だけしかしていません。単純なCRUDなアプリにアプリケーションサービスでやることって、RepositoryをCallすることだけ(と、Transaction)だけなんですよね。Infrastructure今回はDBを使わず、ダミーテーブル的なインスタンスをApplicationScopedで設けました。Repository周りのイメージを整理することだけをゴールとしています。仕様そのものについてですが、注文・発注など一般ユーザーが使う場合はタスクベースの画面構成であるのは正しいと思います。2重Submitも制御しないといけない要件だと、この構成にしておかないと事故につながります(つまり正しい構成)。偏ったエクセルをそのままWebにしたみたいな画面です。いうと、一覧を直接編集して更新する、みたいな画面構成です。何度でも上書き更新するような雑な画面です。最終的なオレオレラッパーフレームワークの仕組みとしては「正しい要件」を満たすのはもちろん、「使用者が限定的な業務システム」もカバーしたいという感じです。コード生成をするか、そもそも方式を含めて見直す必要もあるかも、と思っています。viewActionが動かない?なぜか、f:viewActionが動かなかったです。type="preRenderView"を使いました。お試し実装をするときには問題なく使えたんだけどなぁ、なんでだろ?さいごにまずは、なんとなく、こんな感じかなぁを作りました。なにそれ?と言われる可能性はあります。*2:最終的に生成されるxhtmlの構造はクライアントで確認できるので、どのくらい効果的なのか不明です。(4)はてなブログをはじめよう!vermeer-1977さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。