Posted on 2005-11-15 12:32
canonical 閱讀(232)
評論(0) 編輯 收藏 所屬分類:
Witrix開發平臺
jsp本身提供的是一個有限狀態機模型(FSM)，Web訪問模型直接體現了這一點: action?XXXX。
action對應于方法名，XXX是方法的參數。在這個訪問模型中沒有指出狀態存儲在什么地方，因為它假設后臺是一個整體，構成一個巨大的狀態集。
但
這種模型注定是過分簡化的，所以會有很多的發展。發展的方向就是逐漸精細化，識別出相關的部分，把它們組織到一起。其實可以從各個框架的開發過程來看出這
種演化的過程。
Struts最早只有一個全局配置文件，現在多了一個模塊的概念。WebWork是在Struts之后設計的，提供了一個所謂的package的概念，將
一堆action和interceptor組織到一起，其設計中package的extends屬性看上去是不是有點眼熟。概念多了就要分模塊，這一點在
面向對象之前就存在了，也符合Struts的發展歷程，只是WebWork的這個extends不再是簡單的模塊概念了，而是一種面向對象的設計，只是
WebWork中沒有實現型與名的分離，每個action名對應唯一的一個action，所以package也可以看作是一種完全靜態的對象,只有一個實
例，不是嗎? 我們可以做一個對應，包的namespace大概可以對應于Jsplet中的objectScope,
包名大概可以對應于Jsplet中的objectType, action對應于objectEvent,
差別在于objectScope是完全動態的，并參與Web對象管理，而package的namespace被創造出來之后只起了一個名字區別作用，
Webwork的后續發展會不會在這一點上再做些文章?
再看另外一個地方。前臺頁面顯示需要從模型中拿到數據，那模型對象是怎么管理的，
Jsp本身提供了幾個管理策略application, session, request, page,
幾個action需要共享狀態信息怎么辦？狀態與行為的相關就是對象化了。Webwork2沒有提供對象化的手段，不知道一般人是怎么做的，將所有相關操
作都塞在一個Action里，然后通過一個擴展參數映射? 還是都從session中存取模型對象?
session中的對象是不是越來越多，有沒有人來管一管?
jsplet的核心是objectManager, 它利用objectFactory來創建對象，利用objectName來管理WebObject，這是與網絡無關的, 這里管理的對象也不一定需要響應Web事件。
對
象如果需要響應事件, 實現IEventListener接口，在缺省實現中,
Jsplet用了EventManager來管理objectEvent的響應，大致相當于xwork的工作，只是EventManager是個幫助對
象，由WebObject自己決定是否使用，而且它是每個WebObject自己使用自己的EventManager,
而不是系統全局只有唯一的一個EventManager。
整個objectManager層面都是網絡無關的，當然可以單元測試。
WebEngine最終實現objectManager與web環境的關聯，只是它使用了拉模式。特別是在視圖jsp中調用WebEngine,
其最重要的作用是將thisObj這個變量注入到jsp模型中。this指針其實體現了對象化的很重要的特點:使用局部名而不是全局名稱。
其實XWork本身也是可以脫離Web環境應用的，特別是它可以脫離View來使用，這是它的擴展性的一個來源。
在Webwork
中有一種叫做Model Driven的概念，使用Model
Driven之后在OGNL表達中就可以直接使用model的屬性和方法。在jsplet使用我們自己的tpl模板引擎,
其中token解析策略是thisObj的屬性和方法可以直接使用，也可以通過thisObj.xx來訪問，這就如同this指針的用法。
再次聲明，我無意將jsplet與其它框架在實際使用效果上作對比，所分析的只是Framework整體的概念模型。數據綁定，參數和狀態校驗等與應用相關的功能在我們的框架中都是有著完整的解決方案的，目前不打算討論這些。