一、過濾敏感詞
使用replace方法進行替換效率比較低。
前綴樹使用空間換取時間，但是效率有很大的提高。
-
定義前綴樹
根據(jù)敏感詞構建前綴樹，使用這個構建的前綴樹來檢測待測的字符串是不是敏感的字符串。
image.png
-
-
在util包中定義了一個過濾類
定義前綴樹：
image.png
-
我們在下面加了一個注解，這是比較合理的，也就是在應用啟動之后，樹就已經(jīng)完全構造完成了。
寫在try中創(chuàng)建一個 對象，會在編譯的時候自動加上finally。
在下面的部分，將字節(jié)流轉(zhuǎn)換成了字符流，使用了轉(zhuǎn)換流InputStreamReader，接著又轉(zhuǎn)換成了緩沖流，為了提高讀取效率。
構建樹：
進行檢索：
利用指針3進行循環(huán)更快一點，因為他會先到終點。
-
跳過一些干擾判斷的特殊符號
東亞的文字范圍，東亞的文字范圍不是符號。中日韓。
image.png
測試如下：
二、發(fā)布帖子
當前網(wǎng)頁不刷新，但是仍然訪問服務器并且得到返回結果。并且返回結果還不是網(wǎng)頁。但是能將結果反映在網(wǎng)頁上。
那個驗證碼是嗎？？？
處理json引入一些包：
-
添加一些處理json的工具方法：
json格式的返回結果是字符串：
code:編碼
msg:提示信息
map:業(yè)務數(shù)據(jù)
image.png
測試：
結果：
瀏覽器將其轉(zhuǎn)換成js對象可以得到每一個key對應的結果。
-
Ajax實例
image.png
jquery發(fā)送異步請求的格式是固定的。就是上面的格式。
測試：
在這個過程中，頁面的內(nèi)容和路徑都沒有進行刷新。但是訪問了服務器，也得到了一些結果。
- 接下來開始進行帖子的發(fā)布
-
dao層
image.png -
mapper
image.png
-進行測試
略
-
業(yè)務層
在業(yè)務層，需要進行敏感詞過濾，標簽處理，比如說js標簽，這些標簽可能會對結果造成一定的影響。spring的工具就有這個功能，可以進行敏感詞過濾。
springmvc提供的工具HtmlUtils.htmlEscape()。會將標簽進行轉(zhuǎn)義。
image.png
瀏覽器會提交給我們很多數(shù)據(jù)，因此是post請求
403表示沒有權限：
這里直接加上注解@LoginRequired不就行了嗎？
$.post的三個參數(shù)：
- 訪問路徑
- 發(fā)送參數(shù)
-
回調(diào)函數(shù)
image.png
image.png
沒有登陸的時候，將我要發(fā)布按鈕進行隱藏。
測試：
三、帖子詳情
在首頁的帖子列表頁面，點擊帖子展示帖子的詳情。
業(yè)務層：
通常根據(jù)id進行查詢的時候都會將id拼到路徑中。
@PathVariable（“discussPostId”）int id，int后面的這個變量名稱是可以隨意進行設置的。
這個方法目前是不完整的，后續(xù)還會添加帖子的回復等。
-
處理模板
image.png
utext可以顯示出其原本表示的含義。
5、事務管理
添加評論會用到事務管理的功能。
我們今后的互聯(lián)網(wǎng)項目主要關注的是中間兩種，還要根據(jù)安全的要求來選擇究竟使用哪一個。
數(shù)據(jù)庫是如何保障事務的機制：
spring有一個專門的模塊叫做springdataaccess用來進行事務的管理:
提供一整套API進行管理，數(shù)據(jù)庫可以是關系型數(shù)據(jù)庫或者是NoSql數(shù)據(jù)庫，比如Reies，或者是MangoDB。
編程式事務和聲明式事務都應該去學習，聲明的畢竟簡單，但是假如我們有一個方法，包含很多步驟，但是只有中間的一個小步驟需要進行事務管理，那么，使用聲明的方法進行進行管理需要管理整個方法，不合理。
-
演示spring如何進行這兩種事務管理
寫在AlphaService中：
需求：增加一個用戶和一個帖子，將這兩個功能寫在同一個事務中。
image.png
事務的傳播機制 ：
業(yè)務方法A()可能會調(diào)用業(yè)務方法B()，以誰的業(yè)務方法為準？
事務的傳播機制，還是不明白。
-
測試
image.png
-
編程式事務管理
image.png
調(diào)用回調(diào)函數(shù)的時候回對方法進行事物的管理。
image.png
6、顯示評論
套路就是先開發(fā)數(shù)據(jù)訪問層，然后是業(yè)務層，最后是表現(xiàn)層。
comment類中有一個字段是entity_type，這表示我們針對什么進行的評論，我們是針對用戶，還是評論。entity_id表示用戶的id或者是帖子的id等信息。target_id指向的是某個人。
status 0：正常的，1：刪除禁用的。
評論需要進行分頁查詢。
根據(jù)實體進行查詢，判斷屬于課程的評論還是人的評論或者是評論的評論。
但是目前還不夠完整，還需要進行target的說明，帖子的回復是不需要指明target_id的。
分頁的邏輯居然可以復用：尋思一下
目前都只是顯示評論，還沒有講添加評論呢吧~~
7、添加評論
- 對于增加評論的功能，我們需要使用事務，因為我們需要連帶著更新帖子的評論數(shù)量。
兩個dml操作，因此，我們需要使用事務。 -
數(shù)據(jù)層方法增進：
image.png
-
更新帖子數(shù)量，在discuss_post中進行更新。
image.png
這個信息雖然冗余了，但是方便查找。
數(shù)據(jù)訪問層完事兒了，接著是業(yè)務層
- 增加評論的業(yè)務的方法來了~~這個方法是重點：
這個方法內(nèi)部包含了兩次的DML操作，我們對它進行事務管理。
接下來就是表現(xiàn)層：
在controller中處理表現(xiàn)層的請求，新增加一個controller。
（我有一個小小的疑問，帖子的訪問路徑，是/discuss/detail/discussPostId嗎？？忘了呢~~）
-
最后處理模板：
image.png
下面是自己補充的表單（回復評論）：
下面是回復給某個人：
驗證之后發(fā)現(xiàn)完全可以。
8、私信列表
和某個人之間的多次對話是一個會話。
111->112等價于112->111，因此按照順序進行排序比較合理。
-
mapper文件
image.png
進行測試：
-
接下來開始開發(fā)業(yè)務組件：
image.png
-
接下來是表現(xiàn)層，他有兩個功能，一個是展示私信列表，另一個是點開之后，展示聊天列表。
image.png
image.png
頁面分別是letter和letter-detail。
-
處理表現(xiàn)層
選中一個會話，然后查看會話包含的消息。
返回操作：
9、發(fā)送私信
-
數(shù)據(jù)訪問層：
image.png
- 設置已讀狀態(tài)
集合中未讀的消息的id。
補充內(nèi)容：
10、統(tǒng)一異常處理
對于出現(xiàn)的異常我們都向上拋出，因此對于服務器的三層架構，我們只需要統(tǒng)一處理表現(xiàn)層就好了。
錯誤頁面的文件名稱一定得是error，并且需要在template文件夾下面。
在下面添加一個錯誤：
錯誤頁面也得進行模板的配置。
以上是springBoot對項目自動進行的處理。
但是不太符合我們的預期，服務端報錯按理講應該記錄日志，方便我們進行排查。
下面是依靠spring來實現(xiàn)的。
寫一個新的請求路徑，在發(fā)生錯誤的時候可以統(tǒng)一進行重定向到這個頁面。
以下這個注解只去掃描帶有controller注解的類。
這個其實就是切面了啦，沒有什么神秘的。
但是要區(qū)分瀏覽器向服務器請求的究竟是什么，是網(wǎng)頁還是json數(shù)據(jù)。普通請求還是異步請求。
plain說明返回的是普通字符串，需要手動進行轉(zhuǎn)換。
11、統(tǒng)一記錄日志
攔截器只是針對控制器盡心攔截，但是我們的日志可以是針對所有的方法，因此不能使用攔截器。
很明顯使用面向切面編程即可，千萬不能將系統(tǒng)需求和業(yè)務需求混為一談。
目標對象上可以有很多地方都能織入切面，構造器，成員方法等~~。
我們的userService沒有實現(xiàn)接口，因此需要使用cglib。
前置通知：
一些小疑問：
- 驗證碼刷新算不算是異步請求，起碼算是異步請求吧，頁面也沒有刷新。
- 重新加載當前頁面，刷新頁面是訪問服務器嗎？
- 事務的傳播機制沒明白，很懵逼。
4.回調(diào)函數(shù)表示由某個對象自動調(diào)用嗎？
就像ajax中的function，或者
transactionalTemplate。 - 假如給某一個用戶的回復比較多的時候該怎么辦，它會自動折疊嗎？
6.那個加載頁面是重新向瀏覽器發(fā)出請求了嗎？？
