基于BS架構管理系統的設計問題與對策初探

王乾坤*

（無錫城市職業技術學院語言創意系，江蘇無錫，214001）

引言

基于BS架構的優勢是顯而易見，不僅升級更方便而且對客戶端要求低。客戶只需要有一款合適的瀏覽器即可運行系統。作為管理系統而言與普通網站在設計時存在很大的區別，普通網站的信息多是單向的，客戶主要是從網站上瀏覽數據。而管理系統更傾于與客戶的交互，客戶不僅要從服務器上獲取信息，還需要向服務器提交信息。所以在基于BS架構的管理系統設計時，遇到的問題更改設計要求更高。主要問題集中在瀏覽器兼容性、提交或顯示中文時亂碼以及如何實現前端代碼的復用性。從以上幾方面，筆者從實際設計經驗出發進行了分析和總結。

1 瀏覽器兼容性

當前瀏覽器市場百家爭鳴，不同產品以及各種版本層出不窮。每款瀏覽器為吸引不同客戶群體，設計傾向特性不同。比如360瀏覽器等面向以瀏覽信息為主的客戶，所以提高瀏覽網頁速度，乃至于不惜犧牲部分交互功能(默認關閉JS功能）。作為基于BS架構的管理系統而言，JS的使用是必不可少的。另外，實現同一功能的JS代碼對不同瀏覽器而言，雖大同而有小異。就這么一點點小異，如果設計不當，小則影響網頁效果大則導致設計功能無法實現。

（1）打開第一扇門：先讓 JS運行起來。筆者的做法是在登錄頁即進行偵測是否禁用 JS，如禁用則提示用戶必須打開 JS。具體代碼是：。

（2）對象獲取問題:FireFox獲取對象的方法是document.getElementById(“idName”)；而 IE 方法是 document.idname 或者 document.getElementById(“idName”)。統一方法:document.getElementById(“idName”)；

（3）const問題：Firefox可以使用const關鍵字或var關鍵字來定義常量；IE只能使用var關鍵字來定義常量。統一方法使用var。

（4）event.x與 event.y問題：IE的 event對象有 x,y屬性,但是沒有pageX,pageY屬性；Firefox下,event對象有pageX,pageY屬性,但是沒有x,y屬性。解決方法：使用mX(mX=event.x?event.x：event.pageX；)來代替IE下的event.x或者Firefox下的event.pageX。

（5）window.location.href問題：IE下可以使用window.location或window.location.href；Firefox能使用window.location。解決方法：使用window.location

（6）frame問題:訪問frame對象時IE使用window.frameId或者window.frameName來訪問這個frame對象.frameId和frameName可以同名。Firefox只能使用window.frameName來訪問這個frame對象。另外，在IE和Firefox中都可以使用 window.document.getElementById(“frameId”)來訪問這個 frame對象。

（7）模態和非模態窗口問題：IE可以通過 showModalDialog和 show ModelessDialog打開模態和非模態窗口；Firefox則不能。解決方法：直接使用window.open(pageURL,name,parameters)方式打開新窗口。

（8）firefox與IE的父元素(parentElement)的區別:IE：obj.parentElement;firefox：obj.parentNode。解決方法：因為firefox與IE都支持DOM,因此統一使用obj.parentNode。

（9）document.formName.item(“itemName”)問題：IE 使用 document.form Name.item(“itemName”) 或 document.formName.elements[“elementName”] ；Firefox只能使用 document.formName.elements[“elementName”]。解決方法：使用 document.formName.elements[“elementName”]。

（10）集合類對象問題：IE可以使用()或[]獲取集合類對象；Firefox只能使用[]獲取集合類對象。解決方法：統一使用[]獲取集合類對象。

（11）自定義屬性問題：IE可以使用獲取常規屬性的方法來獲取自定義屬性，也可以使用getAttribute()獲取自定義屬性；Firefox只能使用getAttribute()獲取自定義屬性。解決方法：統一通過getAttribute()獲取自定義屬性。

以上列述了功能問題以及解決方法，另外還有一些外觀以及式樣問題，如Table操作問題、對象寬高賦值問題、CSS透明等等。這里不在贅述。

2 提交或顯示中文時亂碼

在項目中經常會遇到中文傳參數，在后臺接收到亂碼問題。那么在遇到這種情況下我們應該怎么進行處理讓我們傳到后臺接收到的參數不是亂碼是我們想要接收的到的，下面就是一些認識和理解。

（1）get請求url中帶有中文參數，有三種方式進行處理防止中文亂碼：

1）如果使用tomcat作為服務器，那么修改tomcat配置文件conf/server.xml中，在

2）前臺需要對中文參數進行編碼，調用js方法encodeURI(url），將url編碼，然后請求。后臺接受時，需處理Stringstr=newString(request.getParameter("param").getBytes("iso8859-1"),"UTF-8")；

原因：tomcat不設置編碼時，默認是 iso8859-1，即 tomcat默認會以iso8859-1編碼接收get參數。以上操作是將參數以iso8859-1編碼轉化為字節數組，然后再以UTF-8將字節數組轉化為字符串。

（2）解決get請求，后臺接受中文參數亂碼處理的方法(搜索功能帶參數）

1）前臺獲取數據，在js中進行編碼處理encodeURI函數采用utf-8進行編碼，而在服務器的進行解碼時候，默認都不是以uft-8進行解碼，所以就會出現亂碼。兩次encodeURI,第一次編碼得到的是UTF-8形式的URL，第二次編碼得到的依然是UTF-8形式的URL，但是在效果上相當于首先進行了一次UTF-8編碼(此時已經全部轉換為ASCII字符)，再進行了一次iso-8859-1編碼，因為對英文字符來說UTF-8編碼和ISO-8859-1編碼的效果相同。

2）后臺解碼處理

在后臺接收參數時候，首先通過request.getParameter()自動進行第一次解碼(可能是gb2312,gbk,utf-8,iso-8859-1等字符集,對結果無影響)得到ascii字符，然后再使用UTF-8進行第二次解碼，通常使用java.net.URLDecoder("","UTF-8")方法。

兩次編碼兩次解碼的過程為：UTF-8編碼->UTF-8(iso-8859-1)編碼->iso-8859-1解碼->UTF-8解碼，編碼和解碼的過程是對稱的，所以不會出現亂碼。

（3）前后臺參數轉譯的方法

如果以上兩種方法都解決不了問題，那么就是參數轉譯的方法。其原理是：參數傳遞里用英文或數字標識。在接收到以后根據英文或數字標識再轉譯成中文。這種方法對規范化的參數是可行的。但會增加代碼量。另外，對非規范化的文本參數而言，這種方法尚不適用。

3 前端代碼的復用性

（1）前端開發過程中，以下幾個問題尤為突出：

1）前端代碼的復用性差。大多是復制粘貼似的復用

2）前端代碼可維護性差。沒有統一的規范和標準，一個人一個風格，即使有的開發團隊有這個意識要規范，實施起來也很困難。

3）可讀性不強。因為和后端到處是交互。而且有時候邊界很模糊，比如：通常我們遵循mvc的思想進行開發，但是，前端有時候，也存在數據的處理。Js的DOM操作，或者對Json數據的再次處理。顯得有重復。

4）大部分中小型的公司，可能由于技術或者資金等其他客觀原因，使得開發過程根據就不分離前端后端。這就導致了開發效率的降低，質量的降低。付出的代價就是復用性、可維護性差。

5）國內目前大多數的前端開發人員，水平不是很高，而且參差不齊。但是需求量越來越大。因為前端，入門的門檻較低，導致這樣的問題比較嚴重。一般，技術問題很少，有，也就是兼容性的問題了。更多的是：工程類的問題。規范和效率、質量上的矛盾比較尖銳。

（2）如何解決前端復用呢？筆者認為可以有以下兩個思路：

1）盡可能原生，并構建本公司的UI庫

原生js，html搭建的網頁是蠻難維護的，比如一個表單驗證，一大堆if else肯定以后維護或者添加功能上面就麻煩很多。

原生的復用也就是代碼復用，把代碼功能抽象出來，表單驗證的功能都類似吧？把功能抽象到方法，比如驗證字符串的個數，compare，密碼是不是相等，郵箱，手機的驗證，正則表達式的驗證。

傳參驗證。每次我只需要定義驗證規則和傳入input的值就可以。這樣一個驗證的類，我就把今生所需要寫的所有表單驗證的邏輯寫完了。

項目有兩個頁面需要驗證，不要寫2遍if else，調用這個類，傳相應參數。拓展類，拓展規則。這樣你原來的代碼不用改，不需要知道以前一堆jq是什么含義，只需要拓展這個類就可以了。一種好的代碼規范就是拓展而不是修改。

2）適度借助力框架

如angular好的實踐就是在controller里面不要加太多業務邏輯和dom操作。如果我們想復用就別讓它依賴當前controller。angular的指令分裝飾型指令和組件。一般復用就要組件不依賴外部環境，這樣你才能把這個指令用到任何地方。我們把該指令分離，他需要的數據通過屬性傳進去，類似 vue和react的props。另外像react就提倡的web components，它的每個部分都是一個組件，當然數據是props傳入的，他都給想好了。這個組件就比較好復用了，它維護自身的state，一個組件一個state，兩個組件基本上沒有任何的耦合。那么復用就好做多了。組件的通信就通過props，子與父組件的通信就需要全局的事件系統了。react復用是做的很好了，但是它沒有雙向綁定，驗證表單寫起來較麻煩一點，組件間的通信也很麻煩。所以寫react應用的時候，子組件一般就充當渲染組件，上面傳什么參數我渲染什么，而且react組件不要嵌套太深，好的實踐是扁平化，如果用了redux,就會發現如果嵌套太多組件，state是很難維護的。

4 結束語

從客戶體驗角度來說。使用的系統應該穩定、簡單。客戶只需要關心自身的業務即可。所以BS解決了系統安裝與升級的困擾。但BS系統的不穩定性和不方便性特點是未來致力與BS架構發展的開發設計人員，仍需要努力的方向。

[1] 廖旭. 基于 BS架構的 SAP開發技術研究[J]. 中國戰略新興產業,2017,(20).

[2] 許建強. 基于BS架構的檔案登記備份軟件優劣解析與結構優化[J].浙江檔案, 2014(09).

[3] 王成,李少元,鄭黎曉,等.Web前端性能優化方案與實踐[J]. 計算機應用與軟件, 2014,(12).

[4] 趙經緯,周余,王自強, 等.基于 Webkit的嵌入式瀏覽器的研究與實現[J].電子測量技術, 2009, (03).

[5] 李穎,陳敏.瀏覽器不正當競爭案件調查報告[J].競爭政策研究,2015,(01).