WDA-Slides-07.pptx

Size: px

Start display at page:

Download "WDA-Slides-07.pptx"

とよみおおばま
5 years ago
Views:

1 WEB+DB システム ( 応用編 ) 第 7 回 (2016 年 11 月 10 日 ) ショッピングサイトの制作 (1/3)

2 設計制作の基本方針作った部分が目に見えて試しながら ( ある程度達成感を感じながら ) 進める ( 実際の仕事であっても全く見えないと疲労が倍加する ) 動作検証を組み込みながらコーディングの前に仕様を書く (Rspec を [ できる範囲で ] 実践的に導入する ) メッセージは基本は英語として多国語化の一つの言語として日本語を入れて行く画面の修飾は後回しにする (WEB Design については他に参考資料が多いのでロジックを作り上げる部分に力点を置く ) 但し力作であれば加点の対象とします git を使ってバックアップを取りながら進める

3 これまでに作った部分これまで導入した部分 ( 説明の都合上 Rspec を先にすべきだが先に作ってしまった部分がある ) ログイン認証 (devise) を導入した商品 (merchandises) の登録を導入し user_root とした Welcome 画面を作成した

4 多国語化は各自の課題レポート評価の際の必須とはしません基本は英語で ( または全部日本語で ) 画面が作成されていればそれで OK ですですが機会があったらコツコツと多国語化を進めてみて下さい Git によるバージョン管理バックアップと同様に練習になります

5 Merchandises( 商品 ) の登録 :user_rootとして app/views/merchandises/index.html.erb を指定したこの画面ではいきなり商品を表示するここまでの画面テストをどう書くか

6 ログイン認証画面の生成 rails generate devise:views で認証用の画面を生成する ( 編集可能なファイルを用意する )

7 ログイン認証画面のカスタマイズログイン認証画面を確認するために見出し表示を編集する ( このファイルを編集したらこの画面が変わったということを確認するためなので内容は元と違ったものならなんでも良い ) app/views/devise/sessions/new.html.erb 先頭を <h2>log in to Vegetable Market</h2> にしてみる ( 後で照合 )

8 Welcome 画面のテストを合成する Viewのテストの生成は rails g rspec:view welcome index と入力する ( 第 5 回 P28 参照 )

9 スタッフ入口のクリックをテストスタッフ専用入口ここをクリックのここをクリックをクリックするとログイン認証画面が表示されるという動作をテストする

10 Spec/views/welcome/ index.html.erb_spec.rb require 'rails_helper' RSpec.describe "welcome/index", type: :view do feature 'Welcome 画面で ' do scenario 'Click Hereをクリックするとログイン認証画面を開く ' do visit root_path # Welcome 画面 (root) を開く click_on (t :click_here ) # Click Here ボタンをクリックすると # ログイン認証画面が表示される expect(page).to have_content 'Log in to Vegetable Market' end end end

11 Spec/views/welcome/ index.html.erb_spec.rb

12 テストの実行 ( 失敗例 ) spec/views/welcome/index.html.erb_spec.rb の Vegetable Market の V を小文字にして試す予想外の画面だとエラーになる ( テスト記述の誤り )

13 テストの実行 ( 成功例 ) spec/views/welcome/index.html.erb_spec.rb の修正を元に戻す ( 正常動作 ) エラーがなくなるまずエラーが起きたことでテストが動作していることを確認しプログラムを書いて No Error の状態にしながらプログラムを書いていくこのテストは今後仕様が変わるまでずっと有効

14 ログイン認証のテストログインViewのテストは rails g rspec:view devise/sessions new で生成する

15 View テストの書き方 :new...rspec.rb require 'rails_helper' RSpec.describe "devise/sessions/new", type: :view do feature ' ログインとログアウト ' do background do # ユーザを作成する User.create!( 'foo@example.com', password: ' ') end scenario ' ログインする ' do # ログイン画面を開く visit new_user_session_path # ログインフォームにとパスワードを入力する fill_in 'em', with: 'foo@example.com' fill_in 'pw', with: ' ' # ログインボタンをクリックする click_on "Log in" # ログインに成功したことを検証する expect(page).to have_content 'Listing Merchandises' end end end

16 画面側で入力 Box に ID を追加テスト側で指定しているの t 同じ ID をそれぞれの入力 Box に追記しておく

17 View のテスト :

18 View のテストと結果 rspec spec/*/*_spec.rb spec/views/*/*_spec.rb spec/views/*/*/*_spec.rb Devise の下は path が深いことに注意パスワードや ID が間違っていたらログインできないこともテストすると良い

19 入力テストのその他のメソッド click_link_or_button click_link ( リンクまたはボタン ) choose ( ラジオボタン ) check ( チェックボックス ) uncheck ( チェックボックス ) select ( ドロップダウンリストなど ) unselect ( 選択リスト ) attach_file ( ファイルのアップロード ) (Capybara/actions.rb)

20 ここまででカピバラは終わり

21 Merchandises( 商品 ) の登録 :user_rootとして app/views/merchandises/index.html.erb を指定したこの画面ではいきなり商品を表示するこの画面でデータがどう処理されるか

22 Index.html.erb

23 Index.html.erb 先頭部分 p <h1> 見出し </h1> p このページの見出しが記載されている p <table><thead><tr> </tr></thead> p 私の例では 14 行目まで p 設定したい項目の列見出しが列挙されている p 今後多国語化で <%= %> の ruby のタグが入って来る

24 私の例では 17 行目 do merchandise コントローラからデータが渡されるここにデータを渡すのは app/controllers/merchandises_controller.rb の indexメソッド merchandises の画面制御はこの Controller に集められている

25 View と Controller は名前で対応 p Views/merchandises の下には n index.html.erb, show.html.erb, new.html.erb, edit.html.erb などがあった p このファイル名は MerchandisesController の中のメソッド名に直接対応している n うっかり片方だけ変えてしまうとうまく動かなくなる n 今 index.html.erb を調べている è n merchandises_controller.rb の中の def index の記述を調べる n def index は index というメソッドを定義するという記述で end までがこの記述

26 Controller からの流れ MerchandisesController の index = Merchandise.all ハッシュ配列 ) に Merchandise クラスの全データが渡される

27 イテレータによる反復 (17 行目 ) do merchandise %> p 私の例では 17 行目 p は Merchandise から.all で取り出されたハッシュの配列が渡される p ハッシュとは連想配列 p.each はイテレータでこの 1 という配列からレコードを一つずつ取り出して merchandise という呼び名で示し 25 行目の end までに記された内容を反復するという処理を意味する

28 HTML の記述を覗いてみる <tbody> do merchandise %> <tr> <td><%= merchandise.category %></td> <td><%= merchandise.name %></td> <td><%= merchandise.price %></td> <td><%= merchandise.maxorder %></td> <td><%= link_to 'Show', merchandise %></td> <td><%= link_to 'Edit', edit_merchandise_path(merchandise) %></td> <td><%= link_to 'Destroy', merchandise, method: :delete, data: { confirm: 'Are you sure?' } %></td> </tr> <% end %> </tbody> </table> <br> <%= link_to('sign out', destroy_user_session_path, :method => :delete) %> <br /> <%= link_to 'New Merchandise', new_merchandise_path %> Ruby では,print や put, p で文字列を表示するが不要 <%= %> で = が入っている %> や <% end% > には = がない各行の最後にリンクを表示するという処理をイテレータeachによって endまで 1レコードごとに反復している

29 Link 先のパスはどう読むか config/routes.rb で記述されているここからパスに展開される devise_for :users resources :users resources :roles get 'welcome/index' get 'welcome/staff_entry', :to => 'welcome#staff_entry', :as => :staff_entry get 'merchandises', :to => 'merchandises#index', :as => :user_root resources :merchandises # The priority is based upon

30 Routes の名称コマンドプロンプトで rake routes と入力する

31 rake routes の読み方 role GET /roles/:id(.:format) roles#show PATCH /roles/:id(.:format) roles#update PUT /roles/:id(.:format) roles#update DELETE /roles/:id(.:format) roles#destroy welcome_index GET /welcome/index(.:format) welcome#index user_root GET /merchandises(.:format) merchandises#index merchandises GET /merchandises(.:format) merchandises#index POST /merchandises(.:format) merchandises#create new_merchandise GET /merchandises/new(.:format) merchandises#new edit_merchandise GET /merchandises/:id/edit(.:format) merchandises#edit merchandise GET /merchandises/:id(.:format) merchandises#show 左から順に ruby のプログラム中での呼び名 HTML のメソッド URL 処理を実行する controller とメソッド (devise のメソッドのソースは修正できない )

32 HTTP コマンドとメソッドの対応 p merchandises_controller.rb のコメントとメソッド名を対照させてみてみる GET /merchandises GET /merchandises/1 GET /merchandises/new GET /merchandises/1/edit POST /merchandises PATCH /merchandises/1 DELETE /merchandises/1 index show new edit create update destroy

33 HTTP/1.1 Method p HTTP で伝送されるメソッドは GET/POST/PUT/ DELETE などになる p コマンド文字列が Delete になりそれを受け取った際のアクションはサーバ側で決められる

34 Link_to の読み方 (new の場合 ) 私のサンプルでは 33 行目 p p link_to 'New Merchandise, new_merchandise_path コマンドラインでの rake routes の表示では new_merchandise GET p p /merchandises/new(.:format) merchandises#new 画面表示の New Merchandise を new_merchandise_path にリンクさせるとこのリンクのクリックで HTML の GET メソッドで / merchandises/new の URL を開き merchandises_controller.rb の new メソッドで処理されるその結果は同名の views/merchandises/new.html.erb に渡される

35 new.html.erb と edit.html.erb p 3 行目 p render 'form p views/merchandises/_form.html.erb が呼び出される p new も edit もどちらも同じ書式で form を呼び出す Controller では new = Merchandise.new に値が設定されて _form で編集用にデータが渡される edit の場合は指定がなくなった

36 _form.html.erb p 1 行目でフォームに表示する元のデータを記述している n _form.html.erb の 1 行目で展開される作成データはそれぞれ new メソッドや edit メソッドで制作されたハッシュなのでフォームの書き込みボタンが押された際に new からならば POST, edit からば PUT という異なる HTTP メッセージが作成される POST /merchandises(.:format) merchandises#create PUT /merchandises/:id(.:format) merchandises#update n この結果 new の場合には controller の create メソッドで edit の場合は update メソッドで処理される

New による書き込み Create メソッドで処理される # POST /merchandises # POST /merchandises.

$html { redirect_to @merchandise, notice: 'Merchandise was successfully created.' } format.$ json { render :show, status: :created, location: @merchandise } else format.html { render :new } format.

json { render :show, status: :created, location: @merchandise } else format.html { render :new } format.

37 New による書き込み Create メソッドで処理される # POST /merchandises # POST /merchandises.json def create = Merchandise.new(merchandise_params) され merchandise_params] で取り出される respond_to do format format.html { notice: 'Merchandise was successfully created.' } format.json { render :show, status: :created, } else format.html { render :new } format.json { render status: :unprocessable_entity } end end end merchandise GET /merchandises/:id(.:format) merchandises#show Save に成功すると merchandises#show に redirect される

38 プロトコル表示実際のデータの流れは端末に表示される

39 HTML からのパラメータ params[] でパラメータを取り出すことができる HTML 側の form の他に <%= tag :input, { :type => 'hidden', :name => accessory', :value => flower arrangement' } %> などのように input tag の形式で params[] に名前と値を手渡すことができるこの例は params[:accessory] に flower arrangement というデータが渡される Hidden 属性なので入力用の Box は表示されない

40 Model を持たない画面と制御 Welcome 画面と同様に generator で view と controller を生成させる特定の Model の Class を保存するのではなく処理内容に応じて Controller でデータを記録する

41 作りたいシステムのイメージ私の場合には野菜の販売サイトです ( 皆さんは各自のイメージで読み替えて作って下さい ) 出来上がり形を画面から考えてみるこんなことを画面に出したいというものを考えて機能をイメージする

42 テーブル設計の要点第 3 正規形になるように設計するリレーションを適切に張ってデータ間の関係を整理するリレーションとなる情報は最初からクラス名 +ID で名前をつける例 :memos に category へのリレーションを持たせる場合フィールド名は category_id :integer となる

43 Camel 型と Snake 型テーブル設計ではクラス名は Camel 型ファイル名やメソッド名は snake 型となる点に注意して下さい Camel 型 (Camel Cace) の例 ActiveSupport Snake Caseの例 confirmed_orders

44 実体型と関連型 ( 前期 8 回 P4 再掲 ) Relation : 関連 /Table( 表のこと ) 呼び名は関連だが実体を表すもの関連を表すものの 2 種類がある実体 : Entity 対象実世界 ( 物理的な存在でないものもある ) 関連 :Relation 実体間の関連

45 実体型とは ( 前期 8 回 P5 再掲 ) Entity Type: 実世界に物理的に存在するもの学生教員教室ピザ ( メニュー ) 実世界で他と区別して識別できるもの大学授業科目予約のフライト便サークル識別される実体大学の建物は物理的に存在するが大学という組織は必ずしも建物を必要としない

46 関連型とは ( 前期 8 回 P6 再掲 ) Relation Type 二つの実体の関係を表すもの履修 : 学生が科目を履修する予約 : 顧客がフライトを予約する注文 : 客がピザを注文するレンタル : 客がDVDをレンタルする一人の客が複数のDVDをレンタルできる一人の客は複数のピザを注文できる学生は複数科目を履修できる

47 メーカーの用語についてメーカーは和製英語です ( 一応通じるようですが ) 一般に工業製品の場合にメーカーは Manufacturer になりますできるだけ正しい英語を使うように用例などが豊富な辞書を用意してみて下さい私の普段使いは Mac 純正の Wisdom でお気に入り ( おススメという訳ではありませんが ) は alc ですまたは辞書ソフトをインストールしてみて下さい

48 販売日などのフィールド日付については String 型ではなく timestamp 型を使うのが一般的だと思います理由は必要に応じて日付表示のフォーマット指定であるとか日数計算のメソッドなど日付処理に必要なメソッドが使えるということがあります但し日数計算などの対象にならない場合 ( 例えば CD/DVD のリリース日など ) は String 型でもいいと思いますが発売から 1 年以上経った CD/DVD を抽出などという処理が将来的にありそうならばやはり timestamp 型がいいと思います

49 どんな感じの画面にしたいか!

50 機能と手順を考える前期の復習でまずは商品登録 / 商品一覧の画面を先に作ってしまったログインしない人でもショッピングカートに色々と買いたいものを入れてもらいたい次はショッピングカートを設計しようか商品登録は店員だけになるようか商品に写真を入れてみようか Trial and Error でとにかく作りながら考えよう!

51 作るべき画面 ( 主だったもの ) 一般ユーザにとっては Ø 商品一覧 Ø ショッピングカート ( 取り消し / 合計額確認など ) Ø 支払い確認 Ø 発送状態の確認 ( 今クロネコの支店など ) Ø About Us( 誰がこんな店出してるの?)

52 こんな画面にしたい!

53 作るべき画面 ( 主だったもの ) ショップの店員 ( オーナー ) にとっては Ø 販売する商品の登録 Ø 登録した顧客の一覧 Ø 支払い状況の確認 Ø ( 出荷しなければならない商品の確認 ) Ø 出荷するための処理 Ø 売り上げ状況の確認 Ø 在庫の確認

54 作るべき画面 ( 主だったもの ) システム管理者にとっては Ø マスターメンテナンス Ø 店員の登録 Ø 誰もが勝手に店員になっては困る

55 作るべきテーブル Cart( ショッピングカート ) CustomerDetail( 顧客情報詳細 ( 送り先住所など )) PurchaseStatus( 購入 ( 出荷 ) 状況一覧 ) Sales( 売り上げ状況 ) 他にもあるかも知れないあるいは設計変更があるかも知れないでもとにかく作ってみて試してみて考えてみようダメなら設計変更すればいい

56 機能を考える顧客は商品を見てショッピングカートに入れるショッピングカートの中身をみて再考するショッピングカートの中身を確認後レジに進む支払い手続きを行う店員は売り上げ状況を確認し出荷処理を行う出荷したら追跡番号を入力する売り上げ集計を行って会計処理ができるようにする在庫状況を確認し必要ならば仕入れ手配できるようにする

57 開発手順 (1) 前期の復習 Ø 画面を分割してヘッダフッタリンクバーを用意 Ø 商品に画像を添付できるようにするショッピングカートの画面を作る Ø ここからテスト手順を意識する過去に遡って Welcome 画面などに [rspec] によるテストを記述する

58 支払いについて Ø クレジット決済 Ø コンビニ決済 Ø 代金引換など決済代行で検索細かい処理や手続きがあるがここでは決済代行にリンクしたものとして支払いボタンを押したらそのまま支払済に移行するものとして設計する

59 開発手順 (2) 顧客は本気で買うぞと思ったらレジに進むボタンを押して自分の住所などを入力し支払いボタンを押す店員は支払済の商品について直ちに出荷処理を行う ( これはオフライン ; 自動倉庫での出荷システムがあったとしてもここでは別設計 ) 出荷が済んだら追跡番号を入力し顧客が商品が今どうなっているかわかるようにするこの順番で実装して行く

60 何かを作るときは卒研もそうですがそのプロジェクトごとに開発のためのノートを一冊用意すると良い ( 電子的でも良いと思いますが ) Rspec がノートの代わりになるかも知れませんが未確認なのでこんな機能があったらいいとかここの動作がおかしいなど気付いた点をノートに書き留めておく機能の追加は思いつきではなく影響範囲を熟考して行う ( ノートに整理して行く ) PC をノート代わりにしている人はプロジェクト用のメモファイルを作る (IDE で代用 )

61 Spec を設計文書として使うこれまで見てきたこんな動作をさせるという内容を最初に Spec に書いていくそのテストを書いてからプログラムを動作させて動作を確認する

62 権限の制約のテストを書く Devise::TestHelpers の組み込みが必須で現在サンプル作成中です上記参考サイトを見て try してみて下さいテストの中身は別にしてまずどんな動作をさせたいか spec を一つでも多く書いてみて下さい

63 欠席課題 Capybara による view のテストの Spec ファイルを作成しその実行結果を添付して下さい

WDA-Slides-12.pptx

WDA-Slides-12.pptx WEB+DB システム ( 応用編 ) 第 12 回 (2016 年 12 月 14 日 ) 人気投票サイトの制作 (1/3) 設計の基本方針作った部分が目に見えて試しながら ( ある程度達成感を感じながら ) 進める ( 実際の仕事であっても全く見えないと疲労が倍加する ) メッセージは基本は英語として多国語化の一つの言語として日本語を入れて行く画面の修飾は後回しにする (WEB Design