一個網頁的功能

-2：一張單據和表的每條數據最好能夠有生命線，什么時候來的，什么時候變得，誰變得，怎么變的，一直到他的使命完結（比如審批完成，那么他就成為歷史單據，以后只會有人查詢他了，關注點少了）
-1：開發應該知道每個表（每個頁面）都是那些值，什么時候有值，什么時候沒有值。不同角色，不同部門的人可以輸入什么值以及怎么控制。這種文檔如果清晰的話，會給后面接手項目的人很多方便。
0：最好有模板頁面功能，如果用戶輸入單據重復性比較高，那么應該做一個 模板頁面功能，將每個用戶的單據按照他們的想法創建為模板頁面，下次填寫頁面的時候直接選擇該模板頁面，然后修改里面的字段即可，這里要考慮好權限問題，簡單考慮，直接按照用戶控制，只能選擇自己創建的模板，或者別人分享給自己的模板。
1：一個網頁考慮后期維護，應該盡可能單一，最好不要很多功能服用一個頁面
2：頁面當中每個控件應該考慮到隱藏與顯示，可用不可用，每個控件最好應該可以提示出怎么輸入，輸入錯誤應該有校驗信息告知用戶錯在哪里
3：頁面的基本狀態應該是4個，insert，update，query，audit（審批）

3.1 insert頁面，要把最初的單據創建出來，

a.頁面字段的校驗問題
b.頁面每個控件的可輸入值的控制（比如不同角色的人或者不同部門的人下拉列表看到東西不一樣）
c.當然特殊情況可能也會有不同人輸入不同的字段值。比如領導直接填寫單子的話，金額只寫領導建議價格，此時審批流可能直接往后走，那么此時下屬員工的建議價格字段可能就是空的。如果是財務直接分配預算金額的話，那么可能員工建議價格和領導建議價格都不填寫，此時這條數據之后財務建議價格有值。

3.2update頁面
a.能不能改，那些能改那些不能改。每個控件的可輸入值是否需要和創建人的可輸入值一樣，如果不一樣，那么創建人查看頁面的時候如何才能看到這個不在他可用范圍內的值，這些都得特殊處理

3.3query頁面
a.數據控制，行級控制和列級別的控制。比如按照部門控制，按照角色控制，按照用戶控制，能查看哪些單據。列級別的控制，打開單據查看后，能看到哪些字段，一般這點不用怎么考慮，單據每次查看一般都是可以查看所有的。
b.普通的查看頁面是不應該能后修改單據字段的。

3.4audit頁面
a.每個審批節點人可能需要補充一些自己需要補充字段，也有可能會直接修改單據的所有字段。當然只要能夠改字段，補充字段都會涉及到值域的問題，就是可以輸入那些值。

以上所有的東西都盡量在項目初始，或者需求開始的時候把功能盡量封裝好，
目的：
a.前臺頁面寫起來盡量少寫邏輯判斷,或者有判斷的話，盡量封裝到一塊寫，比如js，body里面的內容盡量干凈純潔，可以寫一些注釋。比如采購合同和銷售合同80%字段一樣，但是盡量做成兩個頁面錄入。
b.代碼要很方便的根據頁面狀態和用戶角色部門等控制控件的各種屬性特效，不要每個頁面都是一大段控制代碼，將代碼提煉出來，封裝，每個頁面調用，這樣代碼更加好看。

4：一個涉及到流程頁面，不同的流程步驟會補充不同的數據塊，同時也看到不同的數據塊。這種頁面要做好，除了要有流程步驟的編碼標志，最好頁面的主表數據有個state，標志著流程走到哪一步了。因為除了流程審批的時候會打開這個頁面，還有查看按鈕也會打開這個頁面，而且查看按鈕進來時，并沒有流程編碼標記，只能通過主表的state字段去判斷哪些數據塊可以顯示。
5：一個項目的前臺頁面，總是會用到用戶，用戶部門，用戶角色等信息，所以這塊應該封裝好，最好能夠直接調用。然后其他的一些狀態位，可以在開始的時候就查詢到。然后進行控制。【強烈建議代碼做好分塊。增加可讀性，不要以為把代碼懟進去就行了。】
6：一個頁面的tip提醒很有必要，無論是在列表頁面，還是其他地方，只要是空間顯示不開所有字的地方，都應該鼠標移動過去就顯示出全部字，不然看不全，真的很折磨強迫癥的人。
總結：讓前臺頁面的代碼更加好改，更加好開發，更加好閱讀，開發規范起來（具體在細寫），后續接手項目的人學起來也方便，否則頁面代碼越來越爛，每個接手的人都抱怨，然后自己又不得不繼續打補丁。