咱們將要把db添加到home中去。java
(ns guestbook.routes.home (:require [compojure.core :refer :all] [guestbook.views.layout :as layout] [hiccup.form :refer :all] [guestbook.models.db :as db]))
接下來咱們來修改一下show-guests
方法,讓它來調用db/read-guests
:web
(defn show-guests [] [:ul.guests (for [{:keys [message name timestamp]} (db/read-guests)] [:li [:blockquote message] [:p "-" [:cite name]] [:time timestamp]])])
最後,咱們修改save-mesage
方法,讓它使用db/save-message
來代替將輸入參數打印到控制檯這一步:數據庫
(defn save-message [name message] (cond (empty? name) (home name message "Some dummy forgot to leave a name") (empty? message) (home name message "Don't you have something to say?") :else (do (db/save-message name message) (home))))
如今,就能夠去頁面上刷新看看變換了。能夠試着添加更多的消息進去,來測試一下它是否真的正常運行了。服務器
這個時候你可能已經注意到了在咱們的應用在顯示時間的地方有一個小小的瑕疵,如今的時間就是一串毫秒數值,這個一點也稱不上用戶友好。那麼咱們就來加一個函數來處理這個問題吧。網絡
咱們使用java的一些類(JAVA Interop)來完成這個函數:建立一個SimpleDateFormat
的實例來格式化咱們的時間戳:session
(defn format-time [timestamp] (-> "dd/MM/yyyy" (java.text.SimpleDateFormat.) ;; 建立了 SimpleDateFormat 的實例 (.format timestamp))) (defn show-guests [] [:ul.guests (for [{:keys [message name timestamp]} (db/read-guests)] [:li [:blockquote message] [:p "-" [:cite name]] [:time (format-time timestamp)]])])
好了,如今去看時間確定就正常了~。(這句是我加的)app
如今咱們把最後一件事情作完,就完成咱們留言簿的全部工做了。如今的數據庫建立是依靠咱們在repl中的訪問而建立的,若是要改爲須要的時候建立,咱們就須要往命名空間handler
中添加一點東西。
首先,先將db
的依賴添加進去:編輯器
(ns guestbook.handler ... (:require ... [guestbook.models.db :as db]))
而後,咱們須要更新的是init
函數,使它能在須要的時候判斷數據庫是否存在,若是不存在就建立一個數據庫。函數
(defn init [] (println "guestbook is starting") (if-not (.exists (java.io.File. "./db.sq3")) (db/create-guestbook-table)))
如今每當init
被調用,它都會去確保一遍數據庫是否已經存在了。佈局
前面的例子,讓咱們體會了一下開發Clojure的web應用是一個什麼樣的滋味。可能你已經意識到了,你只須要寫不多的一點代碼,程序就能夠運行起來了,並且寫的代碼幾乎都不是千篇一概的相同。
如今你應該已經對程序的結構瞭若指掌:每一個主要的部分,以及他們是怎樣進行相互間的配合。
當你回憶起來的時候,你應該還記得它有如下的幾個命名空間:
命名空間guestbook.handler
,它負責的是引導和建立將客戶端請求傳遞給服務器端進行處理的程序。
接下來是guestbook.routes.home
命名空間:這裏包含了咱們大部分的邏輯的使用,以及建立咱們實際的工做流(workflow)的地方。若是你須要更多的工做流,你能夠在guestbook.routes
下建立新的命名空間來完成這些:舉個例子,好比你能夠有一個命名空間叫作guestbook.routes.auth
用來處理用戶的註冊以及認證工做。
在應用中,每一個在routes
下的命名空間應該都是一個包含本身的工做流程的封裝。(Each namespace under routes will typically encapsulate a self-contained workflow in the application.)【看到workflow我就不知道怎麼翻譯了!天啊~來個大神救救我!!】 全部的從屬於它的代碼都應該能夠在一個地方找到,而且相對於其它的路由來講應該是能夠獨立運行的。一個工做流能夠進行是處理用戶認證的,也能夠是進行內容編輯,或者進行一些管理。
命名空間guestbook.views.layout
管理的是應用的佈局,其中的代碼都是用於生成普通的頁面以及對頁面的信息進行調整。一般狀況下佈局還將管理一些頁面須要的諸如CSS和Javascript的靜態文件,也會設置一些靜態的頁面元素,好比說header和footer。
最後,咱們還有一個命名空間guestbook.models.db
。這個命名空間維護的是應用的數據模型。其中表的定義決定了數據庫存儲的數據類型。
當咱們開始着手於大型應用開發的時候,這些東西也將保持不變。一個正常的Clojure應用的結構應該是易於理解和維護的。這對你的應用的生命週期來講也是一件好事:你將沒必要像往常在使用其它語言開發程序時候同樣,來瀏覽一個項目複雜的層次結構。
在這裏咱們使用的是Light Table來開發咱們的應用,雖然它簡潔應用,可是在有些方面它仍是有些力不從心,沒有一些IDE提供的有用功能,諸如代碼完成,代碼結構調整等等。
在這一點上,你能夠花時間去嘗試一些其餘的開發環境,好比Eclipse或者是Emac。本書的其他部分都會將Eclipse做爲開發環境(譯者:T^T 我好不容易弄好Light Table! 沒有看後面,不知道是否是真的這樣,後面我就繼續滾回Intellij啦),可是不管你使用哪一個編輯器,你都應該能夠輕易的作好這些事情。
到時候你就會發現,咱們在開發應用的時候會頻繁的使用REPL。它不一樣於任何的IDE,它能夠在你進行開發的時候更快速的執行代碼以及返回結果。
在第一章中,咱們建立好了本身的開發環境,概覽了Clojure的web應用究竟是怎樣的一個組織結構。在下一章節中,咱們將主要關注Clojure網絡棧(web stack)的核心庫上。你將會學習到關於請求/響應的生命週期,路由的定義,session的管理以及使用中間件(middleware)來提高核心請求處理的功能。
第一章結束啦,撒花撒花~
整體感受翻譯的不是那麼的順暢,真對不起本身的第二專業啊…
可是我也慢慢的找到了感受,對於翻譯有任何吐槽都直接說出來把~!
小弟明天就開始繼續上班啦,可是翻譯還會繼續進行下去,畢竟這也是我想要學習的東西嘛。
最好,再次歡迎和我進行交流,提出建議~
email: samuel.m.shen#gmail.com