第3.7式. 動態產生JavaScript
問題
你想要根據從應用模型獲得的數據動態產生JavaScript。
動作要領
使用Struts 標簽在你想要包含在HTML中的JavaScript 代碼中渲染數據：
<script language="JavaScript">
function showMessage( ) {
alert( "Hello, <bean:write name='myForm' property='name'/>!" );
}
</script>
動作變化
上述方案產生了一個JavaScript 函數，彈出一個消息框，消息文本為"Hello, name!" name的值是使用bean:write標簽產生的。此方案展示了使用Struts 標簽創建JavaScript 和它們創建HTML一樣的容易。
JSTL也可以按這種方式使用。
雖然這種方法很明顯，但是很奇怪很多人都在問這個問題。通常問題還可能是："我如何才能從Struts中調用HTML中的JavaScript 函數？" 技術上講，你并不能從Struts調用一個HTML頁面中的JavaScript 函數。Struts 和JSP 技術都運行在服務器端。相反，JavaScript確是在客戶端的瀏覽器中處理的。但是，通過這里所述的動態產生JS的能力，基本上還是相當于所需的這個行為。
這個方法的一個重要基礎是JSP的轉換過程。JSP 頁面由JSP 聲明，標準JSP 標簽 (比如jsp:useBean), 定制JSP 標簽(比如Struts 和JSTP 標簽), 運行是表達式，以及腳本小程序（scriptlets）組成。除此之外的其他東西都是模板文本（template text）。模板文本可以是任何不會被JSP轉換處理的內容。人們通常會認為模板文本就是HTML 標記，但是它其實是JavaScript 或者其他非JSP 處理的文本。JSP 翻譯器并不關心模板文本采用何種形式。因此，你可以象在HTML元素中產生文本一樣容易地在JavaScript 函數中產生文本。
如果你使用JSP 來產生良構的（well-formed）XHTML, 那么動態JavaScript 模版文本必須使用jsp:text元素和CDATA section的方式結合來指定。具體信息參見Hans Bergsten的ONJava 文章：http://www.onjava.com/pub/a/onjava/2004/04/21/JSP2part3.html。
這里的例子僅僅列出了很簡單的使用場景。如果要訪問的模型數據需要使用復雜的JavaScript數據結構，比如，數組，你可以使用迭代標簽，比如logic:iterate和c:forEach來組裝這些結構。
相關動作
下一動3.8或會使用迭代標簽來產生客戶端的JavaScript 數組。
看到JavaLobby上面有篇比較JSF和ASP的文章：
Is JSF ready to take on ASP.Net?
總體來看 JSF逐漸在使Java開發向著更加RAD的方向發展，JB, Oracle Jdeveloper, IBM WSAD/RAD， SUN JSF Creator等等都作的不錯，提供了一定的visual可視化組件開發的能力和數據幫定能力。但是距離MS的可用性還是相差甚遠。
尤其是VS.NET 2005一出之后，這個差距更大更需要努力了。
JSF預計出現的第3方組件市場并沒有出現蓬勃發展，是因為JSF本身沒有起來，還是IDE不夠標準。可能兩者都有，特別是后者，規范中并沒有界定組件需要IDE支持，必須提供的元數據集合，那么到底是針對oracle呢，還是IBM?或者自行其是。
Struts繼續占據著前端框架的霸主地位，WebWork和Tapstry艱難求生。連Spring也將觸角伸到前端。JSF還是困難啊。
Matte Railbe的BLog中有一個關于框架的發展現狀：
去年鬧著玩的《Struts in Action》譯本，想不到網上流傳的還是比較廣泛了。不過去年草稿發出后，再也沒有修改過了。前
幾天翻出來看，倒是有不少錯誤，包括錯別字和翻譯錯誤。
覺得這樣很不好，搞不好誤人子弟。于是決定近日將其重新修改整理，發一個完整半出來。
感興趣的，可以關注我這里的相關信息。我將在這里提供下載鏈接。
JDJ上面有一篇 Duncan Mills 的文章，論述了框架技術的下一個發展，那就是Java世界需要一個元框架（Meta-Framework）。原文地址見：
http://java.sys-con.com/read/49198.htm
他認為，.NET之所以也很成功并且吸引很多人，總體來說，.net的技術成本要低的多（當然商業成本不低），這是因為.Net環境下有一個集成的統一框架，而java世界，則疲于整合各種JSR，各種技術，各種實現和各種框架。從Struts，WebWork, Tapstry, Hibernate, Spring, Keel....框架層出不窮。我們比較、學習、整合.....累啊。
因此，一個元框架的出現，應該符合以下的特征：
- 范圍廣闊（Broad Scope） 框架應該涵蓋從UI，到頁面流控制器，到與多個底層服務 provider的集成，包括EJB, Web services, POJO...。
- 并存（Coexistence） - 框架不能實現所有需要的功能，但是能夠提供可插入的集成點。
- 抽象（Abstraction） -足夠抽象，并且你可以選擇。以便能夠對某些組件的具體實現進行替換。
- 呵呵， 還有長壽（Longevity
- 工具支持（Tooling）
這其中最流行的是什么？POJO，IoC/DIP？想想， 重量級的EJB3.0能否重整雄風？而輕量的Spring已經繁花似錦。另外， JSF整合了JSP, JSTL和Portel API之后，能否成為前端的標準？畢竟標準的事件模型還是令人鼓舞的，而且，瀏覽器的兼容問題也好解決一些。這些都有可能成為metaFramework的候選。
Oracle的ADF已經從ADF UIX遷移到JSF，這下厲害了。ADF(JSF+bizmodule)+TOPLINK， 是否有能夠和 SPring + Hibernate有的一拼呢？
另外，Keel是否顯得比較亂？
而 NetKernel 呢？
看到XML.com一篇關于XForms引擎的評述，
地址是：
http://www.xml.com/pub/a/2005/02/09/xforms.html
-
Chibacon Chiba
-
DENG by way of UGO
-
x-port formsPlayer
-
Mozilla/Firefox
-
Novell Engines
-
OpenOffice and StarOffice
-
Oracle Engine
-
Orbeon Presentation Server (OIS)
-
Zen Interactif xslt2xforms
-
University of Helsinki X-Smiles
-
Honorable Mention: Ripcord Technology nForms