其實到這裡來說，我發現狗書一些沒太講清楚的事情了，當然看著之前的筆記，其實我也知道自己以前也發現了一些問題。
由於我們大部分都是在用拓展包，其實拓展包為我們做了一些什麼事情其實我是完全不知道的。
比如現在我們重點來看一下我們test函式。
/test
", methods=['
get', '
post'])
deftest():
form =nameform()
ifform.validate_on_submit():
session[
"name
"] =form.name.data
redirect(url_for(
"test"))
return render_template("
test.html
", form=form, name=session.get("
name
"))乙個需要說到的點是，什麼時候瀏覽器會傳送post請求，什麼時候會傳送get請求，我們後台是否知道？
單純從上面這段**我們是不知道的。
我們只能猜測在jinja2模板裡面的submit按鈕會觸發post請求，如果只是開啟**，會傳送get請求。
我們是否能指定submit按鈕，按下以後也傳送get請求呢？我們現在不知道。
暫且就按上面的理解來繼續吧。
然後，我們現在主要是解決乙個重新整理頁面，瀏覽器會重複提交上一次請求的情況，當是post請求的話，瀏覽器會不厭其煩的告警。
瀏覽器是瀏覽器的事，我們只能靠我們的後台來做處理了。
那其實就像我們上面的所說的一樣，我們應該是要處理上面那個東東，我要讓按下submit的請求變成乙個get請求，狗書中的redirect其實也是get請求啦。
狗書上是怎麼做的，他直接改成上面的**就實現了。
我一臉蒙蔽，不應該是改前端的**麼？
改後台這麼騷的思路也可以做？
這裡我真的不是特別理解。
但是，也要試圖去理解一下。
我們沒改前端，那麼說明乙個東東，按下submit按鈕後，確實還是發了乙個post請求過來（google瀏覽器開發者模式是不是可以驗證這個說法？）。
後台收到這個post請求後，強制讓客戶端再發乙個get請求過來。這樣導致，按下按鈕後，實際的最後效果，是最後傳送了乙個get請求。
這個思路確實騷。
不像我，傻乎乎的就像去改造前端按鈕傳送的請求。
再來看看上面這段**，好像沒起作用，坑吧，這麼精闢的思路翻車了？
大家可以想想為什麼沒有生效？
因為什麼呢？因為我漏了乙個return。
其實完整的應該是這樣的。
/test
", methods=['
get', '
post'])
deftest():
form =nameform()
ifform.validate_on_submit():
session[
"name
"] =form.name.data
return redirect(url_for("
test"))
return render_template("
test.html
", form=form, name=session.get("
name
"))這樣繼續讓我懷疑之前的一些假設。
假設我剛剛的假定是對的話，好像會有些問題。
我按下按鈕觸發post請求給後台，後台看到你這個東東，**裡面有東西，好，我就給你重定向一下。然後再返回給你test.html。
這樣的話，其實最後請求也是get請求啊...
難道說前面想的是有問題的？
我們再來猜測吧，難道是這麼說？
我們雖說寫的是後台的**，其實並不完全只是後台。其實也有一部分前端的邏輯？
不太清楚，望高人指點...
重新撿起flask（七）
來到資料庫一章，我的心還是很矇的。雖說自己之前sql寫的666，但是你讓我建模我還真沒幹過啊！然後狗書裡用的還是sqlalchemy，用物件導向來理解資料庫，我選擇godie，我知道為什麼叫狗書了.開玩笑啦。不過說實話，是有些懵。因為你在這個框架裡呆的時間還很短，什麼都不知道，你不知道這個框架為你做...
重新撿起flask（五）
又想蹭點東西了.這裡主要是想來複習一下jinja2模板的一些內容。之前其實很快的過了jinja2裡面寫一些if或for控制語句的東西。真到現在想直接寫一些，卻有些忘了，如果你也忘了，我們一起來回憶一些吧。ouch 上面是默寫的，也不知道是不是對的。我仿著思路再寫一下for的吧。不記得有沒有while...
重新撿起flask（四）
中間乙個禮拜沒有看過flask了，今天重新撿起來，一切又開始陌生了。強迫自己看下去，也算是有了收穫。以前大概到這裡就開始沒有怎麼實際寫過 了，其實看書，和實際寫 還真是差的很遠。剛看了沒多久，由於自己現在是自己手敲，所以走了一些彎路，但這些彎路其實對於成長來說，還真是很有用的。這裡我舉個剛剛遇到的例...