前言：
這篇文章本應該在一個月前就寫出來，但是因爲種種原因，腹稿打了數十遍，現在纔有時間提筆來寫。文中某些觀點相對目前的web應用比較前衛，閱讀者應當根據自己應用的具體情況，對此文進行批判的閱讀。by michael chen
一 定義
one page, one application(後面縮寫爲opoa，或者1p1a)，含義很簡單：一個頁面就是一個應用。在衆多的基於web的mis系統中，沒有人關心頁面的組織形式；大多數稍微複雜的mis系統，都採用分禎 (frame)的方式來組織頁面，這樣，在進行業務操作的時候，url的變化表現在一個框架頁面內，從瀏覽器的地址看起來，只有一個地址；更有甚者，一些應用乾脆彈出一個去掉了瀏覽器菜單、工具條、地址欄、狀態欄的窗口（比如招商銀行、民生銀行的網上銀行系統），連地址都看不見。因此，一個頁面就是一個應用，從用戶的角度來說，對於操作型系統，是一種非常自然的體現。用戶無需瞭解每一個具體的操作對應的地址是什麼。
這種設計背後的含義實際是：是希望由程序來控制用戶的行爲，還是反過來。在操作型系統中，每一步的操作往往被業務含義嚴格定義，無論是應用的設計者，還是其使用者，都希望在一種受控的狀況下來進行操作。例如，一個審批動作，用戶更希望是通過一個按鈕來觸發，而不是訪問類似於 /approve.action?itemid=123的方式。
二 場景
顯然，opoa的設計只能針對那些對url不敏感的系統，或者說操作型系統。絕大多數mis系統都屬於這一範疇，email系統也是這一範疇，其他領域，如監控系統，聊天室等都可以採用這種思路。反面的例子是，對於內容型系統，如新聞系統，blog系統，論壇系統，用戶更希望能夠通過一個明確的 url來定位頁面內容，搜索引擎也喜歡這種地址。這種應用需要的是一個合理，易懂，明確的地址。
三 設計與實現
大多數mis系統，無論是有意識或者無意識，都遵循了opoa的思路。要麼採用框架，要麼採用彈出窗口來屏蔽url的直接訪問。實現上也很簡單，這裏就不再贅述了。注意到上述的opoa地實現只是對用戶而言，看起來好像是一個頁面一樣，但實際上還是有衆多的action， page在後面工作。
下面我要說的一種實現是，採用amowa/ajax技術來實現真正意義上的opoa. 簡而言之：主頁面（或者稱佈局頁面）只加載一次，其他的操作頁面通過amowa/ajax技術來加載，並將其中的操作腳本與佈局內容分開，最後進行展示。這個設計的原型在buffalo-1.1dr版本中。細心的開發者一定能注意到，在切換不同demo的時候，只是調用了一個switchpage函數，將不同的頁面進行讀取並顯示。demo的演示速度相當快，因爲每次只讀取一小部分頁面；如果加上緩存機制，將頁面進行緩存，那麼更快了。
首先存在一個佈局頁面，這個頁面定義了一個應用大致的外觀，（例如，大部分mis系統按照上中下三欄，中間部分左右兩欄分別爲頂部logo, 操作菜單，具體操作內容，底部狀態欄）。用你喜歡的網頁編輯工具，將這個頁面設計美觀，然後按照應用的要求，將頁面進行拆分。此時的拆分不用frame 了，只需要在不同的部位加上<div id=”…”>就可以。
然後在主頁面定義一個函數，例如switchpage, 將這個函數使用在需要進行頁面切換的地方。在buffalo的sample中，switchpage函數這樣實現：
function switchpage(page) {
pagebuffalo.remotecall("pageservice.loadpage", [page], function(reply) {
var pageobj = reply.getresult();
buffalo.getelementbyid("body").innerhtml = pageobj.html;
if (pageobj.script != null pageobj.script != "") {
execscript(pageobj.script);
}
});
}
你可以用任意你喜歡的ajax/amowa引擎來做這件事情。
剩下的工作都可以想象了。你可以將web應用的網頁資源全部用html編寫，並放在一個不爲人知的地方，而通過pageservice來讀取他們；你可以任意組織你的應用外觀，更加自如的切換他們。應用的url地址永遠只有真正的一個，你的應用也要比別人快很多，因爲只加載那麼一小塊內容。
四 小結
ajax/amowa的興起爲我們開闊了很多視野。比起原來的web框架，這種opoa的方式能夠更快，減少更多的編碼量，並提供更好的用戶體驗。當然，上文中提出的只是一個原型實現，如果嘗試自行實現，可能更多的東西需要考慮，如安全，緩存，事件回調機制，內存管理等等。但這將是一個方向，一個可以提高開發體驗與用戶體驗的方向。