カテゴリー別アーカイブ: 設計

入力なき出力は、画面に届かない

プログラミングをする際は、常に「入出力を意識する」ことが大事だと思っています。
今回は、更新ページ update.php について取り上げてみます。

入出力、とだけ言われても、何のことやら、という人も多いと思います。
これも考え方は無数にあって、例えば、

1.
index.php に対するリクエスト       → 入力
レスポンスされる php or html ファイル → 出力

2.
関数 getUser(id) の、引数 id    → 入力
戻り値 user (return user;)     → 出力

など、非常に幅広く捉えることが可能です。

「その画面」でどういった「出力(データ)」が必要か、を意識する

闇雲にプログラミングして、出来るときもありますが、
時間がかかるのでおススメできないやりかたです。
常に、「この画面で、どういった出力(データ)が必要か」を意識することが、
プログラミングをスムーズに進める上で、役に立ちます。

今回の update.php についていうと、画面に出力するのに必要なのは、
1ユーザの、名前・e-mail・年齢・コメント
となっています。

ここで、1ユーザというのが 一覧ページ(index.php)との違いです。
意識するべきことは、index.php と違って、全部のレコードを取得・表示ではなく、
ここで必要なのは、1レコードだけなのです。

ただし、一画面だけでは、どのレコードを取得すればいいかはわかりません。
レコードを一つ選択する、キーとなるものが必要になります。
今回の場合は、id がそのキーです。これが入力になります。
前の画面から id 情報を持ってきて、SQL を実行して、
名前・e-mail・年齢・コメントの情報を取得し、表示する、ということになります。

上の書き方に倣うと、

前ページ index.php から渡される id → 入力
そのユーザーの名前等の情報     → 出力

という風になるかと思います。

実は同じような入出力は一覧ページで、ページング(5件づつ表示し、次へ、前へをつける)際にも大事になってきます。
これについては、また後日、取り扱います。

次回は、「PHP でのデバッグ」について予定しています。

シンプルに考える

僕が設計や、実装をする上で心掛けていることに、
「可能な限りシンプルに」ということがあります。

例えば、システム構成。
複数台のサーバーで構築するより、1台で構築した方が、
プログラムの更新を反映するにしても、トラブルの原因を突き止めるのも、やりやすいです。

例えば、テーブル定義。
慣れないうちは、一つのテーブルに様々なカラムを入れてしまいがちですが、
適切なテーブルを、適正な関係で複数のテーブルを作成した方が、
データの登録・更新するには、行いやすいし、パフォーマンスもでます。

例えば、画面遷移。
最近ではSPA(シングルページWebアプリケーション)、
いわゆる1ページで完結しているサイトが、
スマホの普及とともに、どんどん増えてきいます。
ただ、僕はSPAはあまり好きじゃないです。
確かに、ページ遷移がないので、ユーザーはクリックして、
待たされることなく、次のページを見ることができますが、
作る側にとっては一つのページで処理することが増え、
デバッグにも手間がかかるようになります。

先日も、とある映画を見るために、某映画館のサイトを使いましたが、
SPAである場合、リロードする度にそれまでの入力がクリアされるために、
高負荷で繋がりにくくなった場合に、同じ情報を何度も入力する手間が出てきます。
シンプルに 1ページ 1役割にすることで、そうした状況がなくなります。

今回、僕が g’s cms で登録時のフローを考えた際の遷移図が以下になります。

seni1

GitHub上のソースと合わせて見ていただけばと思います。
Topページは index.php で「登録されている一覧を表示」する。
ページ下部に、登録ページ用のリンク regist.php を張り、
「登録情報を入力だけさせる」ページを作成する。
このページで登録した情報は、[登録]ボタンを押すことで、
「登録処理を実行する」 regist_execute.php に遷移。
ただ、登録を実行する URL をユーザーに見せてしまうと、
この URL に対して不正なリクエストをする人が出てきたりするため、
不可視な phpページとして作成し、
処理中にエラーが発生時は、regist.php にリダイレクトし、
成功時は、「登録完了を知らせる」 regist_complete.php に、リダイレクトさせる。

こう作ることで、1ページに 1役割を持たせた画面構成になる上に、
不正な登録を試みるユーザーに対する、若干のけん制にもなります。
(実際は regist.php のソースを見れば、formの先がregist_execute.php であるのは、
この構成では明らかですが、そこはまた別の話)

今回は画面遷移を設計することについてとりあげました。
ただ、「シンプルに考える」というのは、今後、いくつかの場面で、取り上げることになるかと思います。
その際に心の片隅にとどめていただいてもらえればと思います。

次回は、「入出力を意識する」ということについて、取り上げる予定です。