WEBシステムの画面構成について

Question

###前提・実現したいこと
WEBシステムの画面構成についてです。
現在WEBシステムをLaravel5.2にて開発中です。登録や編集についての画面構成についてお聞きしたいのですが通常？新規画面と編集画面は、分けて作成することが一般的なのでしょうか。
というのも、現在の画面構成が１画面で新規/編集を兼ねており、登録項目が１画面で6,70項目あり、かつ動的に変動する部分もあります。

ネットでサンプルを色々と調査してみましたが、大体が新規画面と編集画面(ファイル)が分かれています。
※１画面で兼ねていない。
ただ、分けたら分けたで、画面の修正が発生した場合、２画面分(２倍)修正が発生してしまいます。

実際、新規画面と編集画面が同一の場合、Bladeの方でのValidationチェック後のInput::Oldなどの制御が結構大変で・・・技術力が足りないのもあるかとは思いますが・・・

何分WEBシステム構築での経験がほとんどない為、有識者または色々な経験をされた皆様に教えていただけないかと思っています。

Answer 1

閲覧画面と編集画面を分けるのはよくある話ですが、新規登録画面と既存データ編集画面は分けないのが普通だと思います。
新規であっても既存編集で画面周りのやる事は同じで、

・既にレコードがある場合はレコードを読み出して編集画面の各項目に値をはめ込んでいく → 入力後登録ボタンを押したら既存レコードをupdateする。
・新規登録の場合は空白の編集画面を表示する → 入力後登録ボタンを押したら新規レコードをinsertする。

という流れになると思います。

なので、新規と既存で変わってくるところがあるとすればDB周りの処理になるのではないかと思います。
(DBによっては新規レコードinsertと既存レコードupdateを適切に判断してくれるようですが)

Comments

[Arajin]

ありがとうございます。確かにその通りではあると思います。
ただ、項目が多い場合は、(バリデーション等も含め)IF等が多くなりソース自体が見づらくなるのではないかと思いまして、皆さんはどうされているのかなと思い質問しました。

また、WEBにある色々なサンプルで新規・編集が分かれているのは、サンプルだから？というのが大きいのでしょうか？

[ynakano]

項目が多くてバリデーションが多くなると言うのは、新規レコード追加でも既存レコード編集でも変わらないのではないでしょうか。
ただ、ソースが長くなると言うのはその通りですね。
私の場合、バリデーション部分を共通関数化して外出しする等して可読性・保守性を高めています。

コメントに言及のあったサンプルの件は、具体的に何を指しているか分かりかねるので、私のコメントは差し控えます。

[退会済みユーザー]

手続き型志向の古い人で、処理の外部化に頭が回らない人なのかなこの質問者？

IFなんてユニークチェックしている箇所かパスワード変更チェック場所以外無いはずなのに

[ynakano]

改めて質問文を読み返してみての推測ですが、最初に登録したら以後2度と変更しない/させない項目が多い、という仮定もアリなのかもしれないですね。
もしくは逆に最初に登録する部分はごく少なくて、後から登録する項目が多いとか。
だとしたら画面を分ける意味はありそうです。
(考えすぎなコメントですね)

[Arajin]

haruka-kanata様
すいません。確かに手続き型志向の考えになっているのかも知れません。
バリデーションチェックは、FormRequestで行うつもりではいます。

ynakano様
私の回答の仕方が悪かったかも知れません。
上述通り、バリデーション部分はFormRequestを利用して外部化するつもりではいます。
よくよく考えてみたら、Bladeの記述(初期化の仕方)が分からなかった事について質問したかったのだと思います。
1.Bladeの初期データの記述について
　Validationで戻ってきたold()の部分を含んだ記述について
2.編集画面においてのBladeの記述について
　こちらは、初期状態は、Controllerから初期で渡された情報を設定すればいいかと思いますが、Validationが入った際の事を考慮した記述の仕方

ただ、上記の記述の仕方は、私なりに色々と調べては見ました。
　{{ $value or old('validation戻り') }}
で行けるのではないかとテスト実装中ではあります。

Bladeの記述について、Sample等ではなく、実業務で構築されている方がいらっしゃったらどうされているのかを教えていただければと思い質問した次第です。
(保守性なども含め)

質問の意味が分からなかったら、申し訳ないです。

Answer 2

画面構成と機能、或いは画面自体のコード(ViewのHTML)は、それぞれ1:1である必要は全くありません。
そして画面構成と言うのは一般論がどうであれ、使うユーザーが「コレがいい」というモノがあるのであれば、そのシステム上はそれが正解になります。(余程セキュリティ上まずいとか言う事でもなければ)

validationは共通関数、或いはClass等で管理すれば、新規作成画面側でも編集画面側でも共通して利用する事が出来ます。(修正が必要になっても手間は1度です)

表示するHTMLについても基本的には新規・編集とも共通のテンプレートを用意すればよく、データが渡されていたらinputにデフォルトとしてその値を入れておくようにすれば、新規の時はデータ無しなので空のinput、編集の時はデータがあるので、inputに入力済みの状態で表示
と言う事が出来ると思います。

逆にこういう形にしておかないと、後で画面遷移が少し変わっただけで、処理側のコードもメンテする必要が出てくるので大変ですよ。

Comments

[Arajin]

kunai様
ありがとうございます。
>表示するHTMLについても基本的には新規・編集とも共通のテンプレートを用意すればよく、データが渡されていたらinputにデフォルトとしてその値を入れておくようにすれば、新規の時はデータ無しなので空のinput、編集の時はデータがあるので、inputに入力済みの状態で表示
>と言う事が出来ると思います。
このようなときの場合、例えばControllerでViewに渡す情報生成時に、初期データ作成するイメージでしょうか。
例)名前項目($name)を表示させる場合。
[新規画面時]
public function getCreate() {
//初期値セット
$name = '';
return view('sample')->with('name', $name);
}

[編集画面時]
public function getEdit(Request $request, $id) {
//DBよりIDを取得
$name = DB::table('foo')->where('id', '=', $id)->get('name');
return view('sample')->with('name', $name);
}

[Blade]
<input name="name" type="text" value="{{ $name }}"/>
※HTMLファサードは利用していません。

[kunai]

そのような方法ですね。
ただ、編集時にはレコードのPrimaryKeyをhidden等で渡すのをお忘れなく。

Answer 3

MVCモデルの場合

URL（コントローラー）が違うからといって 表示するHTML（ビュー）やFORM（モデル）が違うかがイコールではありません。

最近のURLルーティング式のフレームワークはこれが基本です。