原因：
在ipad上做一個類似於ibook的軟件，其實相當於用webBrowser展現一套HTML頁面（寫了個JS框架控制內部數據的加載，所謂內部數據就是一套JSON文件和圖片）
需求：
做一套生成他規定的內部數據的工具，要所見即所得，至少也要和他展現形式差不多的形式（HTML頁面）進行編輯保存，PHP編寫，支持導入導出
設計思路：
拋棄書先不談（因為存儲格式未定），理論上：頁面和文本塊，圖片本身是樹狀結構，然后多個頁面構成一個知識點，多個知識點構成一本書，從結構上看樹狀結構，如果要導入這樣的數據進行編輯，那么我的思路是首先構造這樣的樹（在內存里）之后繪制他們
頁面的繪制:
調用頁面類的show方法。如果要繪制頁面那么先構造一個頁面的DOM樹，之后往這個DOM樹上掛載控件，給控件賦值（控件自己的show方法）
知識點的繪制：
一個知識點其實就是頁集合，那么我會繪制第一個頁面（show里調用第一個子對象的show），並在頁面上添加一個導航條可以上下頁滾動（調用指定頁的show）
書本的繪制:
這里直接調用知識點的show會有點問題，因為知識點的滾動需要一個導航條，頁的滾動又要一個導航條，我有個不成熟的想法，如果這樣，我可以讓對象自己的show沒有實現方法，使用一個show對象進行繪制，這樣我就可以使同一個對象在不同的上下文里有不同的繪制方式
整體上看，就是一個組合設計模式，一個解析器，一個DOM操作對象（用接口封裝，使得可以透明的選擇不同第三方的庫）
結果：
老大覺得，你丫這么麻煩干嘛，寫一個操作界面，每個操作用ajax解決，服務端不要架構，用各個小函數解決
問題：請大家客觀分析真的有問題嗎？
架構設計圖：
確實還有一些我腦子里的想法沒輸出出來，其實image,page,text在我腦子里的設計其實是這樣的，在我的內部存儲數據里，我會要求數據長成這樣：
{"divid":"control1","type":"text",value="hello"}
{"divid":"control2","type":"image",value="../image/1.png"}
另外，我會從一個HTML模版里生成DOM樹對象，模版里有兩個DIV，用CSS絕對定位，他們的id就是control1,control2，所以我會在DOM對象里find這兩個元素，find之后，就創建textbox,img對象設置好值，掛上去，這些操作，都在他們自己的show里完成（也就是說，page對象創建DOM對象，然后呢，會在初始化image,text的時候傳遞進去，他們就能在所屬的頁面上進行繪制了）