Struts秘籍之第2段：第3.6式： 從圖像提交表單

第3.6式. 從圖像提交表單

問題

你想要使用戶能夠通過點擊一個不在HTML表單標簽中的圖像來提交表單。

動作要領

適應一個對JavaScript URL 的鏈接來提交表單：

<html:link href="javascript:document.myform.submit(  )">
    <html:img page="/submit-form.gif" 
               alt="Submit" border="0"/> 
</html:link>

動作變化

Web 應用經常使用可點擊的圖像來提交表單而不是僅僅通過表單按鈕。Struts 的html:image標簽可以用來產生一個顯示圖像的HTML input type="image" 標簽。但是，對于復雜的 HTML 布局，并不總是能夠將圖像嵌入在表單<form> . . . </form>標簽之中。有些時候，一個 HTML 頁面可能在頁面的某一段可能有多個表單，而提交頁面的圖像則在頁面的另一個區域。比如，工具條風格的圖像按鈕。

上面的方法可以用于從表單之外的圖像提交表單。所顯示的圖像嵌套在html:link標簽中。該鏈接通過執行一行JavaScript來提交表單。在上面的代碼中，JavaScript 將提交名為MyForm 的表單。表單名稱必須匹配struts-config.xml文件中所配置的action元素的name屬性。下面是這種方法產生的HTML 代碼：

<a href="javascript:document.myform.submit(  )">
    <img src="/myapp/struts-power.gif"
         border="0" alt="Submit">
</a>

雖然你可以直接使用上述HTML標記而不是Struts html標簽，如果那樣的話你將失去那些標簽所提供的特征。通過使用Struts tag，你就不是必須要指定context 名稱，并且你可以使圖像名稱和替換文本來自于資源束 (如果你需要的話)。

另一個辦法是使用html:img 標簽的onclick屬性：

<html:img page="/submit-form.gif"
       onclick="document.MyForm.submit( );"
           alt="Submit" border="0"/>

這種方式的缺點是，有些瀏覽器并不提供圖像是可以點擊的一些可視提示線索。因為圖像嵌入到一個鏈接中，大多數瀏覽器都會在改變鼠標指針以提示該圖像是可以點擊的。

相關招式

第3.9式會描述如何在表單的action屬性中指定的地方將表單提交到另外一個URL。

Struts秘籍之第2段：第3.5式： 在JSTL循環中使用索引屬性

第3.5式. 在JSTL循環中使用索引屬性

問題

你想要在在JSTL c:forEach循環而不是Struts logic:iterate循環中通過Struts html標簽使用索引屬性。

動作要領

為了創建一個簡單索引屬性的字段，可使用bean:define標簽將循環計數暴露為一個可用于運行時表達式的腳本變量：

<c:forEach var="theItem" items="${MyForm.myItems}" varStatus="loopStatus">
  <bean:define id="itemIndex">
    <c:out value="${loopStatus.index}"/>
  </bean:define>
  <br/><html:text property='<%="myItem["+itemIndex+"]"%>'/>
</c:forEach>

如果索引屬性是一個嵌套的bean 并且你使用的是indexed="true" 屬性，那么可以將Struts logic:iterate標簽替換為JSTL c:forEach:

<c:forEach var="theNestedItem" items="${MyForm.myNestedItems}">
  <br/><html:text name="theNestedItem" 
              property="nestedProperty"
              indexed="true"/>
</c:forEach>

動作變化

JSTL的c:forEach標簽提供了一些額外的功能并且比logic:iterate更加易用。需要循環遍歷的條目可以通過使用EL來指定。JSTL 標簽允許對集合的子集上進行更多的控制，并且循環狀態的細節也很容易獲得。然而，如同所有JSTL標簽一樣，沒有腳本變量被創建。我們在其他招式中所過，在處理索引屬性時，不得不使用腳本變量。特別是如果你沒有使用struts-el標簽庫更是如此。

bean:define標簽從JSTL創建的范圍變量中創建一個基本變量。這個bean:define標簽基于取自value屬性或者標簽體的值創建了一個新的范圍變量和對應的腳本變量。后一種方式在JSTL和Struts標簽之間建立了一個橋。在這一招中，bean:define標簽用于創建一個包含可用于訪問索引屬性的索引的變量。你可以在第3.4式中的選擇喜好顏色的標但中使用這種技術。

What are your three favorite colors:
<c:forEach var="theColor" items="${FavoritesForm.color}"
     varStatus="loopStatus">
    <bean:define id="ctr">
        <c:out value="${loopStatus.index}"/>
    </bean:define>
    <br/><html:text property='<%="color["+ctr+"]"%>'/>
</c:forEach>

根據第3.4式，你可以使用Struts-El標簽來消除scriptlet：

What are your three favorite colors:
<c:forEach var="theColor" items="${FavoritesForm.color}" 
varStatus="loopStatus">
  <br/><html-el:text property='color[${ctr}]'/>
</c:forEach>

如果需要為一個對象的嵌套屬性創建一個HTML 輸入字段，而該對象是一個索引屬性，那么請在Struts html 標簽中指定indexed="true" 屬性。indexed屬性的用法在使用JSTL c:forEach循環和使用logic:iterate循環時是一樣的。下面是這種技術如何使用在第3.4式中的表單的喜好鏈接部分：

What are your favorite links?
<table>
    <tr>
        <th>Name</th>
        <th>URL</th>
    </tr>
    <c:forEach var="webLink" items="${FavoritesForm.webLinks}">
        <tr>
            <td>
                <html:text name="webLink" 
                       property="name" indexed="true"/>
            </td>
            <td>
                <html:text name="webLink" 
                       property="url" indexed="true"/>
            </td>
        </tr>
    </c:forEach>
</table>

渲染后的索引值被正確產生，哪怕是使用了begin, end, 和step屬性來控制循環。下面的c:forEach用法演示了如何為集合的第1個和第3個元素產生輸入字段：

<c:forEach var="webLink" items="${FavoritesForm.webLinks}"
         begin="1" end="3" step="2">
    <tr>
        <td>
            <html:text name="webLink" property="name" indexed="true"/>
        </td>
        <td>
            <html:text name="webLink" property="url" indexed="true"/>
        </td>
    </tr>
</c:forEach>

這將產生下面的HTML:

<tr>
    <td><input type="text" name="webLink[1].name" value=""></td>
    <td><input type="text" name="webLink[1].url" value=""></td>
</tr>
         
<tr>
    <td><input type="text" name="webLink[3].name" value=""></td>
    <td><input type="text" name="webLink[3].url" value=""></td>
</tr>

為了在循環中渲染動態數據以供顯示，JSTL 工作的很好，并且比對贏得Struts 標簽更易使用。你可以看到，JSTL 在訪問索引屬性方面比Struts 標簽支持的更好。例如，下面的代碼就展示了喜好顏色可以如何顯示：

<c:forEach var="color" items="${favs.color}">
    <li><c:out value="${color}"/></li>
</c:forEach>

相關招式

第3.4式演示了索引屬性的類似用法。

你可以參考JSTL 的相關文檔和信息，以及書籍。JSTL規范參見http://java.sun.com/jsp/jstl.

Struts秘籍之第2段：第3.4式：在表單中使用索引屬性

     摘要:   第3.4式. 在表單中使用索引屬性 問題 你想要在表單中創建對應于一個Bean中的索引屬性的一套輸入字段。 動作要領 在Struts html標簽庫的標簽中使用indexed屬性來產生屬性值：   <html:form action="TestOneAction"><p>  <logic:iter...  閱讀全文

Struts相關資源

Apache Struts Web Framework官方網站

http://struts.apache.org

Apache Struts Web Framework示例應用和實際應用

1.         SF上的一個Apache Struts 示例應用集

http://struts.sourceforge.net/

其中包括一些很著名和很有用的項目。主要有：

n         AppFuse – 一個非常著名的，優秀的基線示例應用，并擴展到使用多種框架。 其官方網站是：https://appfuse.dev.java.net/ 作者Matt Raible網站是：http://raibledesigns.com/wiki/Wiki.jsp?page=Main 他是Spring Live的作者，也是Apache Struts Web Framework Resume和StrutsMenu的作者

n         Polls – 一個在線調查管理的Apache Struts Web Framework 應用。

n         Struts k Action Invocation Framework (SAIF) – 為Apache Struts 添加動作攔截器和IoC特征。

n        Struts  BSF – 一個使用BSF 兼容腳本語言的 Apache Struts  Action 實現。

n        Struts Cocoon – 集成Apache Struts  和Cocoon，使用Cocoon 作為表現層。

n        Struts  Flow – 將Cocoon的控制流帶入Apache Struts  中

n       Struts  Resume – Appfuse作者的一個例子，使用AppFuse 作為基礎。參見：http://raibledesigns.com/wiki/Wiki.jsp?page=StrutsResume

n         Struts  Spring – 集成Apache Struts 和Spring 框架的集成庫。

n         StrutsDoc – 一個用于 Struts或者 Struts 相關配置文件的JavaDoc風格的文檔工具。

n         AjaxTags – 添加了AJAX功能的 Struts  HTML taglib 的修改版本。

該項目的下載列表中還包括其他一些有用的東西，主要有：

n         artimus   Struts  in action作者編寫，并在書中分析提及的一個應用。

n     Struts  in Aciton 書籍的源代碼

n         Struts  CookBook

2         Apache Struts Web Framework Menu  也是Matt Raible 的作品，http://sourceforge.net/projects/struts-menu/

3         XPlanner 一個基于Web的項目計劃跟蹤工具。JSP+Struts+Velocity+Mysql+Tomcat. http://www.xplanner.org/

4         STXX   Apache Struts Web Framework中通過XSL進行XML變換 http://stxx.sourceforge.net/

5         Liferay 著名的開源Java門戶系統， 使用Apache Struts Web Framework作為前端 http://www.liferay.com

6          

開發工具

1.       Borland JBuilder

2.       IBM Rational Application Developer

3.       Oracle Jdeveloper

4.       BEA Weblogic Workshop

5.       Myeclipse

6.       M7 Nitrox Apache Struts Web Framework IDE

7.       Easy Apache Struts Web Framework, For Eclipse and JB

8.       Apache Struts Web Framework Console

9.       Exadel Studio

其他資源

1.        Strust in Action的作者的資料 http://www.husted.com/struts/ 。其實有這個網站，我這個列表也顯得多余。那就增加一些中文的內容好了。本網站還包括很多Java相關的資源鏈接。

2.        Apache Struts Web Framework官方資源站點 http://wiki.apache.org/struts/StrutsResources

3.        國內主要的Apache Struts Web Framework技術論壇

n         http://www.chinajavaworld.com/

n         http://www.cjsdn.net

n         http://www.matrix.com

n         http://forum.javaeye.com/

書籍（其中紅色部分有中文版）

•     Jakarta Apache Struts Web Framework Cookbook  Bill Siggelkow (February 2005)
•        Jakarta Apache Struts Web Framework Pocket Reference by Chuck Cavaness, Brian Keeton (June 2003)
•        Programming Jakarta Apache Struts Web Framework by Chuck Cavaness (November 2002)
•        Professional Jakarta Apache Struts Web Framework by James Goodwill, Richard Hightower (September 2003)
•          Apache Struts Web Framework Survival Guide: Basics to Best Practices by Srikanth Shenoy, Nithin Mallya (February 2004)  下載該書的電子版 點擊這里
•          Apache Struts Web Framework In Action by Ted Husted, Cedric Dumoulin, George Franciscus, and David Winterfeldt; Foreword by Craig R. McClanahan (November 2002)  網上可以搜索到我翻譯的中文版電子書。
•          Apache Struts Web Framework Kick Start by James Turner, Kevin Bedell (December 2002)
•          Mastering Jakarta Apache Struts Web Framework by James Goodwill (September 2002)
•          Apache Struts Web Framework: The complete reference by James Holmes (April 2004)
•          Professional Apache Struts Web Framework Applications: Building Web Sites with Apache Struts Web Framework, Object Relational Bridge, Lucene, and Velocity by John Carnell, Jeff Linwood (March 2003)
•          The Apache Struts Web Framework Framework: Practical Guide for Java Programmers by Sue Spielman (October 2002)
•          Pro Jakarta Apache Struts Web Framework, Second Edition by John Carnell, Rob Harrop (March 2004)
•       Struts  Recipes by George Franciscus, Danilo Gurovick (July 2004)
•          Apache Struts Web Framework Fast Track: J2EE/JSP Framework: Practical Application with Database Access and Apache Struts Web Framework Extension] by Vic Cekvenich - Sept. 2001 (1st Apache Struts Web Framework Book)
•          Apache Struts Web Framework by James Turner, Kevin Bedell (June 2003)

Web和Services, 能混為一談嗎？

以下是Ted Neward的一個blog，旨在陳清多年來一直可能混淆的概念，即“Web Services”是一個東西嗎？
他認為,其實人們可能都混淆了，Web代表的是互操作性，而Services則是代表一種設計理念，即獨立的、自治的、無耦合的組件模型。而“Web Service”僅是其中的一種結合方案而已。
頗有見地。
下面是摘錄的原文，其中精彩之處予以標出：原文可訪問 http://www.neward.net/ted/weblog/index.jsp?date=20050525#1117011754831

Web + Services

A lot has been written recently about Service-Orientation and Web services and REST and the massive amounts of confusion that seem to be surrounding the whole subject. After much navel-contemplation, I'm convinced that the root of the problem is that there's two entirely orthogonal concepts that are being tangled up together, and that we need to tease them apart if we're to make any sense whatsoever out of the whole mess. (And it's necessary, I think, to make sense out of it, or else we're going to find ourselves making a LOT of bad decisions that will come to haunt us over the next five to ten years.)

The gist of the idea is simple: that in the term "Web services", there are two basic concepts we keep mixing up and confusing. "Web", meaning interoperability across languages, tools and platforms, and "services", meaning a design philosophy seeking to correct for the flaws we've discovered with distributed objects and components. These two ideas, while definitely complementary, stand alone, and a quick examination of each reveals this.

Interoperability, as an idea, only requires that programs be written with an eye towards doing things that don't exclude any one platform, tool or technology from playing on the playground with the other kids. For example, interoperability is easy if we use text-based protocols, since everybody knows how to read and write text; hence, HTTP and SMTP and POP3 are highly-interoperable protocols, but DCOM's MEOW or Java's JRMP protocols aren't, since each relies on sending binary little-endian or big-endian-encoded data. Interoperability isn't necessarily a hard thing to achieve, but it requires an attention to low-level detail that most developers want to avoid. (This desire to avoid low-level details isn't a criticism--it's our ability to avoid that kind of detail that allows us to write larger- and larger-scale systems in the first place.)

This "seeking to avoid exclusion" requirement for interoperability is why we like using XML so much. Not only is it rooted in plain-text encoding, which makes it relatively easy to pass around multiple platforms, but its ubiquity makes it something that we can reasonably expect to be easily consumed in any given language or platform. Coupled with recent additions to build higher-order constructs on top of XML, we have a pretty good way of representing data elements in a way that lots of platforms can consume. Does interoperability require XML to work? Of course not. We've managed for the better part of forty years to interoperate without XML, and we probably could have kept on doing quite well without it; XML makes things easier, nothing more.

Services, on the other hand, is a design philosophy that seeks to correct for the major failures in distributed object and distributed component design. It's an attempt to create "things" that are more reliable to outages, more secure, and more easily versioned and evolvable, things that objects/components never really addressed or solved.

For example, building services to be autonomous (as per the "Second Tenet of Service-Orientation", as coined by Mr. Box) means that the service has to recognize that it stands alone, and minimize its dependencies on other "things" where possible. Too much dependency in distributed object systems meant that if any one cog in the machine were to go out for some reason, the entire thing came grinding to a halt, a particularly wasteful exercise when over three-quarters of the rest of the code really had nothing to do with the cog that failed. But, because everything was synchronous RPC client/server calls, one piece down somewhere on the back-end meant the whole e-commerce front-end system comes to a shuddering, screeching pause while we figure out why the logging system can't write any more log messages to disk.

Or, as another example, the First Tenet states that "Boundaries are explicit"; this is a well-recognized flaw with any distributed system, as documented back in 1993 by Wolrath and Waldo in their paper "A Note on Distributed Computing". Thanks to the fact that traversing across the network is an expensive and potentially error-prone action, past attempts to abstract away the details of the network ("Just pretend it's a local call") eventually result in nothing but abject failure. Performance failure, scalability failure, data failure, you name it, they're all consequences of treating distributed communication as local. It's enough to draw the conclusion "well-designed distributed objects are just a contradiction in terms".

There's obviously more that can be said of both the "Web" angle as well as the "Services" angle, but hopefully enough is here to recognize the distinction between the two. We have a long ways to go with both ideas, by the way. Interoperability isn't finished just because we have XML, and clearly questions still loom with respect to services, such as the appropriate granularity of a service, and so on. Work remains. Moreover, the larger question still looms: if there is distinction between them, why bring them together into the same space? And the short answer is, "Because individually, each are interesting; collectively, they represent a powerful means for designing future systems." By combining interoperability with services, we create "things" that can effectively stand alone for the forseeable future.

And in the end, isn't that what we're supposed to be doing?