電子商務系統的設計與實現(十四)：菜單高亮

標籤：web前端   菜單高亮   url匹配   

    菜單高亮，幾乎是所有Web網站都需要的一個功能。

   這個功能，說起來，簡單得很，給當前頁面的菜單增加一個高亮樣式，刪除其它菜單的高亮樣式。

   如果只高亮1個頁面的菜單， 太簡單了，但是如果菜單和頁面比較多，就產生了爭議。

   第1種方式：每個頁面單獨高亮。
  

<li id="indexli"><a href="${base}/">首頁</a></li>    <script type="text/javascript">function highlightIndex() {highlight("indexli");}      function highlight(id) {$("#" + id).addClass("liactive");}</script> 

   好處：靈活性非常強。
   壞處：每個頁面都需要增加一個高亮菜單的方法。

第2種方式：通過匹配URL， 唯寫一個高亮菜單的方法。
        

     var url = window.location.pathname;//預設為‘首頁’indexvar current = ‘index‘;if (url.indexOf(‘/service‘) != -1) {current = ‘service‘;} else if (url.indexOf(‘/case‘) != -1) {current = ‘case‘;} else if (url.indexOf(‘/article‘) != -1) {current = ‘article‘;} else if (url.indexOf(‘/code‘) != -1) {current = ‘code‘;} else if (url.indexOf(‘/about‘) != -1) {current = ‘more‘;} else if (url.indexOf(‘/news‘) != -1) {current = ‘more‘;} else if (url.indexOf(‘/help‘) != -1) {current = ‘more‘;} else if (url.indexOf(‘/ask‘) != -1) {current = ‘ask‘;} else {current = ‘index‘;}for (var i = 0; i < navList.length; i++) {if (i == map[current]) {navList[i].className = ‘liactive‘;} else {navList[i].className = ‘‘;}} 

好處：菜單高亮邏輯處理，都在一個地方。
壞處：靈活性很差，對URL有比較嚴格的要求。
簡單說就是，URL的規則越簡單越統一，匹配越簡單。但是URL如果有例外的情況，就必須做特別處理。
當再增加一個URL的時候，需要考慮新增的URL和已有的URL匹配規則是否產生衝突。

-----------------------------------------------------------
上述2種方法我都用過，說說我的感受。
如果URL比較隨意，就在每個具體的頁面單獨調用高亮函數。
如果URL非常統一，可以統一處理。

在實際過程中，比如公司的項目中，關於採用哪種方式就產生了爭議，前端希望統一處理，後端傾向於單獨定製。
後端開發過程中，url比較隨意。前端希望後端把url規範命名，按照菜單的組織來定義url。
而boss則不願意這麼做，他認為菜單和後端url並不需要嚴格統一，菜單和後端業務不應該有過強的依賴。

就我們公司的項目和我自己的項目，我更傾向於每個頁面單獨調用高亮函數，非常靈活。
有的頁面，只需要高亮最頂層菜單，有的頁面，還需要高亮左側的菜單。

至於高亮菜單的邏輯，可以封裝成方法。

無論你增加了多少頁面，每個頁面的高亮，都不會互相影響。
-----------------------------------------------------------
再吐槽幾句，封裝菜單邏輯，每個頁面調用一次高亮函數，分分鐘就搞定的事情。非要去寫統一的URL匹配，花費個把小時，還不能保證完全正確，並且， URL匹配也不能在多重專案之間複用。

團隊開發就經常存在這麼類似的很多問題， 導致開發效率非常低。

so，我認為，一個優秀的全棧式開發工程師，和5個人的小團隊開發效率差不多。 

電子商務系統的設計與實現(十四)：菜單高亮