canonical

引用:

如果在Action Centric的框架，要避免兩個(gè)訪問點(diǎn)，可以這么定義。 view.do?&templateName=a &objectName=/@Demo&objectEvent=test

這 種做法就是程序自己處理而不是框架支持了。我說過，工作就是那么多，只是框架做什么和程序作什么的分工而已。說jsplet是page為中心也不太準(zhǔn)確， jsplet是以對象為中心，只是指定了希望使用的視圖頁面而已。view.jsp放在前面只是jsp實(shí)現(xiàn)上的一個(gè)問題，

引用:

Action Centric 確實(shí)比較麻煩，必須同時(shí)傳入角色列表 和 用戶列表的 分頁信息。 JSPLet對于這個(gè)問題是怎么處理的？

很簡單包含兩個(gè)子頁面
list_both.jsp
<jsp:include page="role_list.jsp?objectName=/@RoleManager" />
<jsp:include page="user_list.jsp?objectName=/@UserManager"/>
在 訪問的時(shí)候通過指定eventTarget參數(shù)即可將事件路由到合適的對象，沒有響應(yīng)事件的對象thisObj里的內(nèi)容不變，因?yàn)榍芭_view顯示內(nèi)容也 不變。注意這里role_list.jsp和RoleManager, UserManager對象都是獨(dú)立開發(fā)的。

引用:

這個(gè)時(shí)候，role_list.jsp 和 user_list.jsp里面都有一個(gè) thisObj。而且這兩個(gè)thisObj的scope都是 sesession ?

注 意所有的對象模型都需要狀態(tài)保持機(jī)制，所以thisObj確實(shí)被保持在session中。在webwork2中如果希望在多個(gè)action之間協(xié)調(diào)，則必 須將某個(gè)對象保留在session中，否則就是采用無狀態(tài)模型，所有的狀態(tài)數(shù)據(jù)都持久化在數(shù)據(jù)庫中，每次輸出的頁面都和某個(gè)action產(chǎn)生綁定（一種行 為相關(guān)），則根本無法實(shí)現(xiàn)上述例子中的分解過程，因?yàn)樵赼ction模型中狀態(tài)與行為無法抽象到一起并重用！ 當(dāng)頁面顯示邏輯比較復(fù)雜的情況下，頁面本身也有一些臨時(shí)狀態(tài)需要保持，MVC并不是意味著所有的狀態(tài)都是需要持久化到數(shù)據(jù)庫中的關(guān)鍵業(yè)務(wù)數(shù)據(jù)。在每個(gè)層次 上都可能需要保持狀態(tài)，MVC只是說某些狀態(tài)變量更加重要，可以驅(qū)動(dòng)其它層次而已。
另外說thisObj的scope是session也是不 準(zhǔn)確的。首先注意到j(luò)splet通過對象化實(shí)現(xiàn)了將狀態(tài)和行為抽象到一起，此后程序就擁有了對這個(gè)整體的控制權(quán)，在jsplet中存在著對象的生命周期控 制，對象的scope是自定義的，對象的生命周期是session的子部分，而不是整個(gè)session生命周期范圍內(nèi)都存在。請注意一下這種控制策略帶來 的可擴(kuò)展性。我們擁有了對象生命周期的控制權(quán)，依然可以采用無狀態(tài)設(shè)計(jì)，但在需要保持狀態(tài)的時(shí)候，可以做到。而在webwork這樣的action模型中 是沒有這種選擇權(quán)的。

引用:

session過度使用是不好的

thisObj只是允許使用session,是否使用session可以自行決定，這是一種使能技術(shù)，而沒有object支持，結(jié)果是無法有效的使用。另外，請仔細(xì)看清楚，objectScope是一種非常精細(xì)的資源使用控制手段。

另 外不要把設(shè)計(jì)理念和性能混為一談。設(shè)計(jì)體現(xiàn)的是對概念的把握，能夠達(dá)到合適的抽象，而性能是實(shí)際實(shí)現(xiàn)過程中的限制。在概念能夠支持的情況下，可以采用技術(shù) 手段解決性能問題，或者退化到較低的層次，這是一種選擇權(quán)。而概念無法支持的情況下，就需要各種穿墻打洞的方法來實(shí)現(xiàn)。

thisObj重要的是概念，如果需要，它可以把狀態(tài)序列化到cookie或者dotNet那種參數(shù)中，這只是個(gè)實(shí)現(xiàn)問題。

引用:

JSPLet Action 必須是 JSP ?

當(dāng)然可以是任何java類， JSP Action只是IEventListener接口的一個(gè)實(shí)現(xiàn) 。在jsplet最初的版本中，action只能寫在java文件中。稍后改為可以寫在jsp中也可以寫在java中

引用:

WebWork的Action本身就是模型對象

這是WebWork弱的地方，它因?yàn)槭腔赼ction的，沒有對象化，所以只有以action作為模型對象的載體，無法捕獲多個(gè)action之間的狀態(tài)相關(guān)性。
完全無狀態(tài)的設(shè)計(jì)正是因?yàn)闆]有合適載體造成的。而jsplet中thisObj可以看作是對session的局域化，是對session的分解。jsplet中的很多概念在webwork這種面向action的框架中都能找到對應(yīng)，只是加上了很多限制并且變得模糊了。

引用:

沒有model1簡易(jstl+javabean) 沒有struts的"優(yōu)雅" 定位模糊.

jsplet 是以非常精煉的方式實(shí)現(xiàn)對象化。再說一次，不要把jsplet的定位向那些開源框架上靠。jsplet的開發(fā)時(shí)間大概與那些開源框架同時(shí)進(jìn)行的。仔細(xì)看看 設(shè)計(jì)中的可擴(kuò)展性。xwork的所有特性jsplet都可以實(shí)現(xiàn)，而且jsplet多提供的部分就是對象化。

可 以使用 并不意味著必須使用，所有無狀態(tài)設(shè)計(jì)都可以一樣應(yīng)用。jsplet是一種事件驅(qū)動(dòng)設(shè)計(jì)，在這一點(diǎn)上，更像是Tapestry或者JSF。基于 actioin的設(shè)計(jì)是真正的無能使用session，它不敢應(yīng)用session的原因是它對session沒有控制力。而在jsplet中對 session的使用控制是很自然的：當(dāng)你需要對象的時(shí)候，當(dāng)你需要這個(gè)狀態(tài)的時(shí)候，它才存在。它出現(xiàn)是因?yàn)樾枰嬖凇Ｔ诿嫦騛ction的框架中，你 仍然需要解決狀態(tài)問題。只是框架無法提供支撐，自己解決而已。
我想，大概大多數(shù)人開發(fā)的程序都是CURD的堆砌，所以很難理解一個(gè)復(fù)雜的應(yīng)用中的狀態(tài)管理的必要性。有了對象支持之后，才構(gòu)成整個(gè)框架的概念上的完備性。

   在Jsp Model 2模型中, 用戶的所有請求提交給Controller Servlet, 由Controller進(jìn)行統(tǒng)一分配, 并且采用推的方式將不同的UI顯示給用戶。 這種推方式在很多人看來是一種優(yōu)點(diǎn)，因?yàn)樵赟truts等MVC實(shí)現(xiàn)中具體推送的UI可以在配置文件中配置，配置完成后還可以通過一些可視化分析工具得到 整個(gè)站點(diǎn)地圖。在Model2模式中基本的訪問格式為:
       action.do?其他參數(shù)  

我 本人從未應(yīng)用過Model2模式，但與我們的jsplet框架對比，我認(rèn)為這種推送方式在大多數(shù)情況下并不是什么優(yōu)點(diǎn)。如果將一次web訪問看作是一次函 數(shù)調(diào)用，則按照Model2模式，這個(gè)函數(shù)的返回情況是不確定的，需要由一個(gè)額外的配置文件來確定。而我們知道，一個(gè)返回情況不確定的函數(shù)一般不是什么良 好的設(shè)計(jì)。在我們的框架設(shè)計(jì)中，一個(gè)基本的觀點(diǎn)是盡量將自由度暴露給實(shí)際控制它的人。實(shí)際上，在大多數(shù)情況下，頁面編制人員知道應(yīng)該使用哪個(gè)頁面來顯示數(shù) 據(jù)，他們并不需要一個(gè)額外的配置文件。Jsplet使用如下的url格式:
       視圖jsp?objectName=模型對象名&objectEvent=響應(yīng)事件名&其他參數(shù)
舉一個(gè)具體的例子:
   http://my.com/demo_view.jsp?objectName=/@Demo&objectEvent=test

demo_view.jsp是指定的顯示頁面, 其代碼如下:
[code]
<%@ include file = "/engine.jsp" %>
<!-- 相當(dāng)于在jsp模型中增加了一個(gè)新的變量thisObj，從而實(shí)現(xiàn)jsp頁面的對象化 -->
<c:out>${thisObj.testVar}</c:out>
[/code]
objectName被WebEngine映射到session中的一個(gè)對象，在demo_view.jsp中成為thisObj這個(gè)變量，這就相當(dāng)于java語言中的this指針，從而實(shí)現(xiàn)了jsp頁面的對象化。

WebEngine還將objectEvent映射到一個(gè)Action響應(yīng)函數(shù)并自動(dòng)調(diào)用它，具體的Action代碼寫在一個(gè)獨(dú)立的java文件或者jsp文件中。
DemoAction.jsp
[code]
<%@ include file = "/jsp_action_begin.jsp" %>
<%!
    //
 // objectName映射為thisObj, objectEvent=test映射對actTest的調(diào)用
 // 在這里增加一個(gè)actXXX函數(shù)之后，即可通過objectEvent=XXX來訪問，不需要任何配置
    public Object actTest(){
  // thisObj中的變量可以在視圖中使用
  thisObj.set("testVar","hello");
  return success();
 }

 // 如果存在actBeforeAction函數(shù)，則該函數(shù)在所有action函數(shù)之前調(diào)用
 public Object actBeforeAction(){
  return success();
 }

 // 如果存在actAfterAction函數(shù)，則該函數(shù)在所有action函數(shù)之后調(diào)用
 public Object actAfterAction(){
  return success();
 }
%>
<%@ include file="/jsp_action_end.jsp" %>
[/code]

在Jsplet框架中只需要注冊對象，而不需要單獨(dú)注冊每個(gè)action。
register.jsp
[code]
<%
    WebEngine.registerType("Demo", new WebActionType("/demo/action/DemoAction.jsp"),pageContext);
%>
[/code]

與Jsplet 框架對比，Model2是對action的建模而不是對object的建模，即它相當(dāng)于將objectName,objectEvent和 view.jsp綁定在一起定義為一個(gè)訪問點(diǎn)action.do,綁定過程中需要一個(gè)配置文件來固化view.jsp和action之間的聯(lián)系。因此, Model2并沒有完全分離view和model，它隱含假定著objectName只具有一個(gè)objectEvent, 并且綁定了一個(gè)具體的view(出錯(cuò)頁面除外)。
例如, 我們需要兩個(gè)不同的view來顯示同一個(gè)數(shù)據(jù)，則在Model2程序中可能需要配置兩個(gè)獨(dú)立的訪問點(diǎn)，而在我們的框架中只需要使用兩個(gè)不同的url:
a_view.jsp?objectName=/@Demo&objectEvent=test
b_view.jsp?objectName=/@Demo&objectEvent=test
同樣的web程序甚至可以在前臺通過XMLHTTP方式來調(diào)用而不需要額外配置!

在Jsplet框架中采用的是對象化的方式而不是Action化的方式，因此存在著多種面向?qū)ο蟮臄U(kuò)展,而所有的擴(kuò)展都直接體現(xiàn)在url格式的細(xì)化上，一切都在陽光下。
  在Jsplet中objectName是WebObject的名稱，在全系統(tǒng)內(nèi)唯一，其格式定義為: objectScope@objectType$objectInstanceId
1. 對象類型objectType
  我們需要注冊的是對象類型而不是完整的對象名，一個(gè)對象類型可以對應(yīng)于無數(shù)個(gè)完整的對象名，例如我們注冊了Demo類型的WebObject, 則objectName=/@Demo和objectName=/left/@Demo對應(yīng)的處理文件都是DemoAction.jsp。
2. 對象生命周期控制objectScope
  objectScope為WebObject所在的域，其格式符合Unix路徑命名規(guī)范。JSP模型本身支持一些預(yù)定義的對象域，包括page, request, session, application等。但為了能夠反映現(xiàn)實(shí)世界中的對象組織結(jié)構(gòu)，對象域必須是允許自定義的。objectScope被組織成一個(gè)樹形結(jié)構(gòu)，這是一個(gè) 基本的控制結(jié)構(gòu)，其控制策略為
     同時(shí)存在的對象域之間必須存在線性序關(guān)系(order)
  當(dāng)系統(tǒng)訪問某一對象時(shí)，如果該對象所在的對象域不能和現(xiàn)有對象的域處在同一"路徑"下(即當(dāng)對象域之間不能建立父子關(guān)系時(shí))，系統(tǒng)就會自動(dòng)銷毀不兼容路徑 分支下的所有對象。 這種精細(xì)的控制策略保證了系統(tǒng)的可擴(kuò)展性，因?yàn)槟Ｐ蜕峡梢员ＷC始終只有一部分對象被創(chuàng)建。
對象轉(zhuǎn)移                                                           系統(tǒng)動(dòng)作 
/main/@MyObject ==> /main/left/@OtherObject                       無
/main/left/@OtherObject ==> /main/@MyObject                       無
/main/left/@OtherObject ==> /main/left/@MyObject                  無
/main/left/@OtherObject ==> /main/right/@MyObject                自動(dòng)銷毀/main/left子域下的對象，如/main/left/@OtherObject
 
3. 對象實(shí)例標(biāo)識 objectInstanceId
 如果在某一對象域中需要包含多個(gè)同一類型的對象，可以通過objectInstanceId來加以區(qū)分，這樣在同一個(gè)頁面上我們可以使用多個(gè)同樣類型的對象。

Jsplet中另外一個(gè)擴(kuò)展是通過事件路由來支持jsp子頁面的對象化。例如
http://my.com/demo_main.jsp?objectName=/@Main&eventTarget=/@Sub&objectEvent=test
如果指定了eventTarget參數(shù)，則objectEvent由eventTarget對應(yīng)的對象來響應(yīng)。
在jsp文件內(nèi)部我們可以通過include語法來引入子對象，例如
   <jsp:include page="sub_view.jsp?objectName=/@Sub" />
（注：我不是非常清楚Tapestry具體是如何實(shí)現(xiàn)對象化的，熟悉Tapestry的朋友可以介紹一下）

在Jsplet中可以通過配置文件來支持對Action的interception, 例如
[code]
<factory>
<listener-filter  class="global.LogFilter" />
<post-listener class="global.CommonActions"/>

<type name="Demo">
 <!-- 如果未指定object, 則缺省為WebObject類型 -->
 <object class="demo.MyWebObject" />
 <listener>
  <filter event="query*|select*" class="demo.LogFilter" />
  <url-listener url="/demo/DemoAction.jsp" />
  <url-listener url="/demo/DemoAction2.jsp" />
 </listener>
</type>

</factory>
[/code]
在上面這個(gè)配置文件中，DemoAction.jsp和DemoAction2.jsp是chain關(guān)系，即事件響應(yīng)的傳播模型中，如果event沒有被標(biāo)記為stopPropagation,就會傳遞到下一個(gè)listener。

綜上所述，可以看到在目前多變的需求環(huán)境下，Model 2已不是一種非常完善的Web程序模式，一些重要的設(shè)計(jì)需求在Model 2模式的推方式中很難得到合適的表達(dá)。

在witrix平臺中訪問數(shù)據(jù)庫最直接的方法是使用edu.thu.db.SQL類。基本用法如下:
//  設(shè)定數(shù)據(jù)庫連接參數(shù)， 連接可以通過java.sql.DriverManager 和

//javax.sql.DataSource等多種方式建立，并支持?jǐn)?shù)據(jù)庫連接緩沖池。
TransactionMode db = new TransactionMode("default"); // 設(shè)定數(shù)據(jù)庫連接參數(shù)
SQL sql = SQL.begin().select().field("id")
                     .from().table("other_table")
      .where().like("name","a%");
   .end();
int n = SQL.begin().select().countAll()
                   .from().table("my_table")
       .where().gt("value", new Integer(3)) // value > 3
            .and().in("type", new String[]{"a","b"})  // type in ('a','b')
         .and().in("data_id",sql)  // data_id in (select id from other_table where name like 'a%')
      .end().query(db).intValue();

在SQL類的設(shè)計(jì)中體現(xiàn)了三個(gè)設(shè)計(jì)原則:
1. 正交化的流式設(shè)計(jì)
2. 參數(shù)對象化
3. bug-free設(shè)計(jì)

首先，SQL類將構(gòu)造SQL語句，連接數(shù)據(jù)庫以及查詢結(jié)果類型轉(zhuǎn)換分解成了三個(gè)正交的部分。
在一般的數(shù)據(jù)庫編程中，我們需要如下訪問方式:
String sql = "select count(*) from my_table where value > ?";
Connection conn = getConnection();
PreparedStatement stmt = null;
try{
     PreparedStatement stmt = conn.prepareStatement(sql);
  stmt.setParameter(1, valueLimit);
  ResultSet rs = stmt.executeQuery();
  rs.next();
  int ret = rs.getInt(1);
  // ...
}finally{
 try{
  if(stmt != null)
   stmt.close();
 }catch(Exception e){
     e.printStackTrace();
 }

 try{
  conn.close();
 }catch(Exception e){
     e.printStackTrace();
 }
}

從 以上的例子中，我們可以注意到，在普通JDBC編程中，設(shè)置SQL語句的參數(shù)，建立數(shù)據(jù)庫連接，取得結(jié)果集中的結(jié)果并轉(zhuǎn)化為合適的格式這三者之間是交織在 一起的。特別是打開連接需要配對的關(guān)閉連接語句，造成整個(gè)程序的流程不是線性的, 因?yàn)槲覀儾荒苷f建立連接之后就可以不再管連接的事情了，我們必須記住在做完所有其他事情之后還要關(guān)閉連接。    通過一系列的封裝對象，SQL類實(shí)現(xiàn)了一種正交化的流式設(shè)計(jì)，其分解模式如下:
      SQL.begin().拼接SQL語句.end().建立連接并運(yùn)行SQL語句.轉(zhuǎn)化結(jié)果()
注意在SQL語句執(zhí)行之后是不需要顯式關(guān)閉連接的。

SQL類的第二個(gè)設(shè)計(jì)要點(diǎn)是參數(shù)對象化。在witrix平臺中，實(shí)際運(yùn)行SQL語句的引擎函數(shù)是
 IDbEngine.execute(String sqlText, List sqlParameters, int resultType, int concurrency);
這 里sqlText, sqlParameters等都是參數(shù)，但是在應(yīng)用中構(gòu)造這些參數(shù)的過程很復(fù)雜，并且非常靈活，一般的Util類（靜態(tài)Utility函數(shù)）無法提供有效 的簡化。 所以構(gòu)造SQL語句這個(gè)過程不是通過util類完成的，而是通過一個(gè)專用的SqlBuilder對象。SQL的基本思想是將sql語句納入java程序框 架，使得sql語句成為程序中可控制的部分。首先SQL類將sql文本與sql參數(shù)封裝為一個(gè)完整的對象，使得sql語句的重用成為可能。其次， SqlBuilder類通過一種可控制的方式構(gòu)造sql語句（所有的關(guān)鍵字都對應(yīng)于一個(gè)函數(shù))，整個(gè)過程與直接書寫sql文本類似，但函數(shù)封裝使得我們能 夠在同一行上指定sql文本中用到的參數(shù)，而不是象jdbc里那樣，集中指定參數(shù)。同時(shí)SqlBuilder支持面向java語言的擴(kuò)展，如直接支持 java集合類型等，從而大大簡化了sql語句的構(gòu)造，因?yàn)橐话鉺ql拼接中最混亂的部分就是牽涉到循環(huán)與判斷。
  參數(shù)對象化的方法還可以應(yīng)用于那些具有大量缺省參數(shù)的地方。在SQL類中，如果我們希望以scroll insensitive的方式選出數(shù)據(jù)，調(diào)用方式如下:
  SQL.begin().select().star()
             .from().table("my_table")
   .end().scrollable(true).list(db,3,100);
如果我們希望利用Statement.cancel()特性，我們可以指定cancelMonitor參數(shù)
   SQL.begin()....end().cancelMonitor(monitor).query(db).listValue();

SQL 類的第三個(gè)設(shè)計(jì)要點(diǎn)是bug-free。jdbc中最常出現(xiàn)的錯(cuò)誤是忘記關(guān)閉連接造成資源泄漏，在SQL類中，連接只在需要時(shí)才從緩沖池中獲取，當(dāng)數(shù)據(jù)庫 操作完成（無論成功或失敗）時(shí)，數(shù)據(jù)庫連接會被自動(dòng)關(guān)閉(或返回連接池)，并自動(dòng)處理提交和回滾的情況。整個(gè)程序代碼中一般沒有需要顯式關(guān)閉連接的要求， 從而極大的降低了資源泄漏的幾率，避免了這個(gè)錯(cuò)誤的出現(xiàn)。這就如同java沒有要求程序員顯式釋放內(nèi)存，從而在絕大多數(shù)情況下避免了memory leak的bug一樣。

 Unix中的Pipe模型被認(rèn)為是Unix最美妙的思想之一: 大量獨(dú)立的小工具通過管道組合在一起，可以構(gòu)成非常復(fù)雜和多樣化的功能。例如:dir|sort。 這是一種功能正交分解的做法，其隱含的一個(gè)基本假定是這些小工具之間具有完全的對稱性，即Pipe模型本身沒有限制哪些工具可以組合在一起，也沒有限制這 些工具組合時(shí)的順序。當(dāng)系統(tǒng)逐漸復(fù)雜起來，對稱性發(fā)生破缺(Symmetry Broken)，則出現(xiàn)了Layer模型，即在不同層次上的對象不能互換， 而同一層次上的對象仍可以互換， 例如協(xié)議棧。更加復(fù)雜的系統(tǒng)中，完整的重用一個(gè)對象變得越來越困難，組件技術(shù)通過接口將對象分解為正交的子部分，最終構(gòu)成一個(gè)網(wǎng)狀模型。

cocoon的文檔中有這樣一段話：
Traditional Web applications try to model the control flow of a Web application by modeling the application as a finite state machine (FSM). In this model, the Web application is composed of multiple states, but the application can be only in one state at a time. Any request received by the application transitions it into a different state. During such a transition, the application may perform various side-effects, such as updating objects either in memory or in a database. Another important side-effect of such a transition is that a Web page is sent back to the client browser.

    Servlet模型提供的正是一個(gè)最基本的基于IO的FSM模型：應(yīng)用程序的狀態(tài)變量存儲在session中，應(yīng)用程序根據(jù)用戶請求更新session中 變量的值。這里一個(gè)隱含的假設(shè)是session中的變量是不相關(guān)的，因?yàn)閟ervlet模型中沒有提供任何機(jī)制來同時(shí)操縱一組相關(guān)變量，例如我們在 session中存放了三個(gè)變量name, title, data, 如果我們希望刪除這三個(gè)變量，我們必須通過三次獨(dú)立的函數(shù)調(diào)用來完成，servlet模型本身并不知道這三者之間的關(guān)聯(lián)關(guān)系。
    當(dāng)web應(yīng)用程序逐漸變的復(fù)雜起來，這個(gè)最簡單的FSM模型就顯得力不從心了。因此發(fā)展出了MVC模型(Model-View-Controller)， 這是對有限狀態(tài)機(jī)的一個(gè)精細(xì)化。首先我們識別出session,request中的變量之間存在相關(guān)性，而且變量之間的地位也是不平等的，某些變量的改變 將直接導(dǎo)致另外一些變量的改變。因此變量根據(jù)相關(guān)性被聚合起來，構(gòu)成很多對象。應(yīng)用程序的狀態(tài)不再由一個(gè)個(gè)獨(dú)立的變量構(gòu)成，而是由具有更豐富語義的對象構(gòu) 成。在大的結(jié)構(gòu)方面，一些基本的對象被分離出來，構(gòu)成一個(gè)核心,即model層, 而外圍的變量被分割在不同的view中。 在流行的struts和webwork等MVC框架中，變量的聚合都定義在action層， 各個(gè)相關(guān)的action并沒有匯聚成一個(gè)具有獨(dú)立意義的對象，似乎僅僅做到了model層和view層的分離，在model層內(nèi)部并沒有建立合適的模型， 即struts和webwork等建立的MVC模型中隱含假定整個(gè)model層內(nèi)部是沒有結(jié)構(gòu)的（注，我對struts和webwork的了解限于簡單介 紹文檔，這里的說法可能并不準(zhǔn)確)。一些更加精細(xì)的MVC架構(gòu)直接支持model層的分解，即model層由一系列不相關(guān)的對象構(gòu)成，每個(gè)對象具有從屬于 自己的action。沿著這個(gè)復(fù)雜性發(fā)展的級列繼續(xù)下去，我們可以知道，當(dāng)對象之間的交互變得更加復(fù)雜的時(shí)候，我們需要框架本身能夠直接支持model層 對象之間的相關(guān)性。最簡單的控制關(guān)系是樹形結(jié)構(gòu)，即父節(jié)點(diǎn)控制子節(jié)點(diǎn)，父節(jié)點(diǎn)銷毀的時(shí)候子節(jié)點(diǎn)自動(dòng)銷毀。這樣就構(gòu)成所謂的HMVC (Hierarchical MVC)模型。在這個(gè)模型中，model層由一系列的對象組成，而且這些對象被分割到不同的package中，組成一個(gè)樹形結(jié)構(gòu).

   控制論的基本哲學(xué)是：對于一個(gè)未知的黑箱系統(tǒng)，仍然可以根據(jù)觀察建立控制模型，簡言之，即控制有理。無論是物理系統(tǒng)，生物系統(tǒng)，社會系統(tǒng)，其控制的機(jī)理是 一致的。這里所強(qiáng)調(diào)的是一種廣義的建模，即我們并不尋求該系統(tǒng)本質(zhì)上的物理模型，而是尋求一種"有用"的模型。實(shí)際上，在數(shù)學(xué)上早已準(zhǔn)備好了多種廣義模型 系列，最典型的Taylor展開可以建立不同級次的多項(xiàng)式模型，我們所要做的只是根據(jù)不同的需要去做擬合。

   關(guān)系數(shù)據(jù)庫的理論基礎(chǔ)是集合論，而集合的基本定義就是不重復(fù)的一組元素。而xml數(shù)據(jù)庫方面尚缺乏相應(yīng)的理論來消除數(shù)據(jù)冗余性。
   關(guān)系數(shù)據(jù)庫能夠成功的另外一個(gè)重要原因是它采用平面表形式，而應(yīng)用中大量使用的正是平面表，所以數(shù)據(jù)庫表在很多時(shí)候是數(shù)據(jù)的最適表現(xiàn)形式，使用xml表達(dá) 只會增加不必要的復(fù)雜性。平面表的基本假設(shè)是所有條目的結(jié)構(gòu)都是一樣的（具有一個(gè)header），而xml表示形式本身不存在這樣的假定，因此很多時(shí)候無 法根據(jù)數(shù)據(jù)的shape來做有效的優(yōu)化。當(dāng)然xml schema等技術(shù)正在快速發(fā)展的過程中，當(dāng)相應(yīng)的元數(shù)據(jù)描述和使用技術(shù)逐漸成熟之后，xml的處理方式會得到本質(zhì)的提高。
   xml技術(shù)是目前元語言的代表，它最重要的技術(shù)優(yōu)勢在于它是人與機(jī)器都能輕易理解的語言，是人機(jī)共享的信道! 目前它并不適合在應(yīng)用程序中表達(dá)復(fù)雜的多維關(guān)聯(lián)。特別是目前多數(shù)操縱xml的API都是面向文檔的，所存取的數(shù)據(jù)類型都是字符串，更造成了程序應(yīng)用上的困 難。

一個(gè)技術(shù)的成功，在于最終占據(jù)了某個(gè)概念。當(dāng)我們應(yīng)用到此概念的時(shí)候，首先想到的就是這個(gè)技術(shù)實(shí)現(xiàn)，久而久之，形成一個(gè)自我證明的過程。而有些技術(shù)卻是在 其位無能謀其政，實(shí)在是讓人不得不為它扼腕嘆息呀。jsp tag正是這樣一種技術(shù)。有些人認(rèn)為jsp tag只是jsp的一種擴(kuò)展，只是一種syntax suger, 這正反映了此技術(shù)所面臨的一種困境。這里指出一些jsp tag的設(shè)計(jì)缺陷，并無貶低這種技術(shù)的意圖，只是希望拋磚引玉，引發(fā)大家對這種技術(shù)改進(jìn)的探討。
引用:
jsp tag是服務(wù)器端的擴(kuò)展標(biāo)簽機(jī)制，它是一系列java服務(wù)器端技術(shù)的基礎(chǔ)。但其設(shè)計(jì)之初的幾個(gè)重大缺陷已經(jīng)使得這種技術(shù)不堪重負(fù)。  

對比dotNet平臺我們可以知道，需要一種后臺標(biāo)簽機(jī)制，jsp tag是唯一的標(biāo)準(zhǔn)（JSF等機(jī)制都依賴于此)，可它的設(shè)計(jì)給所有希望基于它開發(fā)的開發(fā)人員造成了巨大的困擾。實(shí)際上我對這個(gè)技術(shù)感到很失望，當(dāng)然我們提 出了相應(yīng)的替代方案。在我們的開發(fā)框架中使用的是重新設(shè)計(jì)的一套與網(wǎng)絡(luò)無關(guān)的xml動(dòng)態(tài)標(biāo)簽機(jī)制。我的觀點(diǎn)是基于jsp tag技術(shù)，無法開發(fā)出與dotNet的便捷程度相當(dāng)?shù)姆?wù)端技術(shù)，所以這是它作為標(biāo)準(zhǔn)的罪過。jsp tag不應(yīng)該是jsp的補(bǔ)充，它搭上了xml這條大船，應(yīng)該去走自己的路，而不應(yīng)該成為應(yīng)用上的雞肋。
引用:
1. jsp tag與jsp 模型緊密綁定，使得業(yè)務(wù)邏輯很難抽象到tag中。而且脫離了jsp環(huán)境，在jsp tag上的技術(shù)投資將一無是處。  

這里說業(yè)務(wù)邏輯可能是有些不妥，容易引起誤解。因?yàn)槲业墓ぷ髯鲈谥虚g件層，所以我的原意是基于jsp tag開發(fā)一系列的擴(kuò)展技術(shù)，比如緩存等。我們的xml標(biāo)簽技術(shù)是與jsp模型無關(guān)的，在前臺用于界面渲染，在后臺用于工作流描述。而且很方便的就可以與 其它xml技術(shù)結(jié)合，比如集成ant。

引用:
2. jsp tag的編碼邏輯非常繁瑣, 特別是寫loop和容器類標(biāo)簽的時(shí)候。在2.0之前不支持從tag本身產(chǎn)生tag更是應(yīng)用上的主要障礙。  

這絕對是個(gè)重大問題，試問多少人自己去開發(fā)jsp tag呢，多半是用用別人的成品。編制困難其實(shí)就是否定了界面元素的重用。很多人推崇Tapestry, 其實(shí)如果jsp tag技術(shù)方便一點(diǎn)，何必建立一個(gè)完全不同的模型呢。

引用:
3. 使用將xml標(biāo)簽的屬性直接映射到對象屬性的方法造成tag對象是有狀態(tài)的，不得不通過丑陋的pool機(jī)制來解決性能問題。
而且性能問題直接限制了大量小標(biāo)簽的使用。  

這是一個(gè)現(xiàn)實(shí)的困難，一個(gè)系統(tǒng)設(shè)計(jì)師必須考慮。

引用:
4. jsp tag是一種完全動(dòng)態(tài)化的設(shè)計(jì)，大量可以在編譯期進(jìn)行的優(yōu)化都無法進(jìn)行，基本上所有的運(yùn)算都是在運(yùn)行期發(fā)生，限制了性能的提高。  

我們的xml標(biāo)簽技術(shù)是先編譯再運(yùn)行的，加上無狀態(tài)設(shè)計(jì)，在性能上可以得到控制。我的朋友hotman_x是個(gè)C++和js高手，在他的強(qiáng)烈要求下，我們的xml標(biāo)簽還增加了一個(gè)多次編譯的機(jī)制。

引用:

5. 雖然最近的版本已經(jīng)支持xml格式，但對于xslt等的集成很不到位，例如現(xiàn)在無法使用xslt對jsp文件進(jìn)行界面布局。

最簡單的
<web:template src="test.tpl" xslt="layout.xslt" />
<web:mytag xdecorator="face.xslt">
...
</web:mytag>

引用:
6. jsp tag要求使用自定義標(biāo)簽名，而無法對已經(jīng)存在的html標(biāo)簽進(jìn)行enhance, 造成無法方便的在可視化編輯器中進(jìn)行編輯。  

Tapestry就認(rèn)為它比較好。我們的xml標(biāo)簽機(jī)制也支持屬性擴(kuò)展。

引用:
7. EL表達(dá)式竟然不支持調(diào)用對象函數(shù)

很多人因此覺得OGNL比較好。我們的機(jī)制中是對EL做了一定的增強(qiáng)。我不喜歡OGNL, 過于復(fù)雜了。