s06068工数管理システムを題材にRails開発の練習を始めています。DFD、ER、テーブル定義と画面のモックアップを作成し、最初の1画面を実装します。実装面では今回は複数テーブルを扱えるようにフォーム用モデルを扱えるようにします。最初に設計をしていますが、これは実装を迷わないようにする意味が大きいです。実装をする段階で矛盾、誤りがあれば見直していきます。DFDとERとテーブル定義です。最初にこれだけのものをざっと設計してしまうのは、実装時に迷わないようにするため、もう少し言えば、データフローがつながらない(=機能・画面が足らない、遷移が足らない)かを検討しています。つながらなくなってしまうのは、DFD上の「プロセス」(マルの部分)が不足していたり、ER上の関係が適切ではなく、インプットからその時その時で必要な情報が辿れないといことが考えられます。*1ある程度イけそうだという確証が持てたら実装に入っていきます。DFDERテーブル定義DFD上のプロセスはおおよそ画面と一致するように書いています。トップページは遷移だけで何もデータは触りません。工数表新規作成が事実上の最初のページで、まずはここから作ります。<モックアップ><実際の画面>作ったコントローラとトップページ私の直感では、DFD上のプロセス1つにつき1コントローラが作られる、と思っています。トップページと、そのうち作るであろうヘルプページ用に、静的ページを扱うコントローラを1つ、新規作成画面を扱うコントローラを1つ定義しました。ルータの定義でいえば下記のようにしてあります。:create]トップページは工数票の新規作成に向けてリンクしています。%>工数表新規作成のページネーミングセンスがちと怪しいですが、事実上このページがアプリの初期化処理に相当するので「AppInitializesController」としました。画面を作るにあたっては下記の点を、このアプリにおけるルールにしました。2つ目以降のルールは次以降の記事に続きます。フォーム用の「モデル」を定義する画面とコントローラ間でデータをやり取りするためのモデルは基本必ず定義することにします。Railsチュートリアルでは、テーブルと対になるモデル(=例えばUser)をフォームデータとしても扱っていました。テーブルとは関係ないデータの受け渡しの例はログインフォームのところで出てきます。login_path)」のように「:xxxx」としているので、View→Controllerへの受け渡しはできますが(params[:session][:hogehoge])、その逆はできないと思われます。1画面で3テーブルを扱う以上はテーブルと対になるモデルは使えません。そこで、フォーム用のモデルを「form」ディレクトリに定義します。)endattr_accessorは画面項目の分だけ作っています。」を定義しているので、自動的に「_confirmation」の項目が定義されます。*2formディレクトリに入れているのは、後々モデルがいっぱいになってしまいそうだからですが、このままではこのディレクトリがパスに入っていないため認識されません。」に下記を追加します。cで「Rails.application.config.eager_load_paths」で確認)これで、ViewとControllerの間でやり取りするためのフォーム用モデルが使えるようになりました。次回は、項目やValidate時のエラーメッセージの日本語化をやっていきます。SI屋さんが使うには使いやすいんじゃないでしょうか。*1:DFDを、GETやセッションから受け取るパラメータのレベルまで詳細に書くともはや立派な詳細設計書です。私が以前いた現場では、新人に「詳細なDFD」を書くよう推奨していました。書かなくても実装できるならともかく、新人だとテンパってしまって書けなくなるので、実装で迷わない為というのが目的です。*2:個人的には、Railsチュートリアルをしている時からテーブル≠画面なのですから、「画面項目のモデル」に「確認欄」のValidateをかけるなら理解できるが、「テーブルの1行を表すモデル」に「確認項目」のValidateがあるというのが「違うんじゃないか?」と思っていました...。