Howard Lewis Ship從13歲起就義無反顧的沉迷於編程。他從1997年起開始開發Java Web應用。在2000年他成立了Tapestry項目。他是Tapestry和HiveMind項目（都是Apache Jakarta的子項目）的開發負責人。他撰寫了Tapestry的權威著作，Manning出版社出版的《Tapestry in Action》一書。他現在是一名獨立的諮詢師，專長是Tapestry的培訓和指導。他和他的作家妻子Suzanne居住在美國麻省波士頓附近。
Hi Howard 自我介紹下吧。
好的，我是Howard Lewis Ship。我是Tapestry項目的創建者和開發負責人，Tapestry是一個創建Web應用的開源Java項目。最近，我又從Tapestry分離了一些技術併發起了另外一個叫HiveMind的項目，它是一個service的框架，用於更便利的方法創建應用。
那什麼是Tapestry還有它的由來是什麼？
Tapestry是在我經歷的基礎上創建，當時我在波士頓一家叫Primix的諮詢公司上班。在那裏我們有一個大小非常適合的團隊，8到10個涵蓋了各種經驗層次的員工。有一些非常年輕、剛從大學出來的新手，通常分配給一些經驗豐富的老員工來帶。我們在做Java方面的工作，使用初期版本的J2EE。甚至有更早的時候，我們還在最原始的那種經常會出來一大堆問題的Servlet和JSP平臺上開發過，通常並不能得到期望的結果，太鬱悶了，每個項目看起來都陷入了痛苦的深淵。在加入Primix之前，我曾接觸過WebObjects，它是Apple公司的一個基於控件的開發web 應用的 framework。經過初步的使用及自己寫的一些小演示來初步體驗，讓我看到了使用控件方法開發web應用的無窮魅力。正好我在Pipeline那一段時間沒有什麼項目，大約有一到兩個月左右時間比較閒，期間我寫完了一些初步的代碼，然後它逐漸就成爲了Tapestry。我繼續完善它，花了好幾周完成了第一個原型。然後不斷的不斷的給它添磚加瓦，整個過程非常有趣。
請問Tapestry和Struts以及其它的一些web framework有什麼區別？
如果你觀察一下Struts，WebWork或是其它一些framework，它們都是以操作爲核心，將URL映射到某個操作。這些操作可能被稱作是Servlet或是Action。當你在創建這些Servlet或Action時候將會受到各種約束。因爲在J2EE服務器裏面，一切都是多線程的。因此你不能使用實例變量，你必須將你的業務邏輯放在Action裏面某個地方，然後又將狀態信息存放在request或是session等另外的地方。你的大量精力將會陷入在這些問題裏面，要考慮怎麼樣命名參數，怎麼樣構建URL，怎麼樣將URL映射到Servlet，怎麼樣返回給客戶端參數。熟練的開發者好象都已經習慣這些了，但很難期望所有的人，尤其是新手也要在這樣的環境開發。我們揹負這些沉重的負擔，多線程基本上是一個基於事件的模型，而不是傳統的桌面類型。
Tapestry是以控件爲核心。就是說你的應用是頁面組成的，頁面是由控件組成，控件也可由控件組成。Tapestry有一個完整應用所需要的一系列藍圖，它可以爲你做很多工作，通常這些都要你自己動手來做。比如自動幫你處理和調用URL。你僅需要創建控件然後告訴Tapestry當你點擊鏈接或提交表單時調用這個控件即可。你會發現很多代碼你都不用寫了，因爲它已經包含在framework中，它已經寫好在那裏並且經過了測試。你知道servlet是很難測試的。因此讓framework多做些工作，爲應用提供頁面，控件等形式的藍圖。它會承擔大部分枯燥無味的重複工作，承擔大家都比較煩的那部分開發和測試工作，因爲這些工作如果你自己來做，沒做好以後就會帶來麻煩。
這聽起來有點象JSF。你對JSF標準是怎麼看待的？Tapestry和它比較有何區別？
JSF它來了來了來了呵呵……。JSF它是那種boogie man類型，追趕着其它所有的web application framework。我想JSF和我們的範圍和目的不同。它是JSF模型的一部分。
你剛提及到JSF，JSF它承諾有工具支持，不知道Tapestry有沒有工具支持的計劃？
我剛說過，在Tapestry裏面，你最重要的工具是你的HTML可視化編輯器，如Dreamweaver什麼的軟件就能很好的工作。如果你使用Eclipse平臺，加拿大Intelligent Works的Geoff Longman已經實現了一個非常優秀的Eclipse插件Spindle。Spindle在我的書中強調得不夠。它確實是一個非常好的工具，因爲在Tapestry裏你需要創建HTML模板，Java代碼還有XML的頁面配置文件等。但是這些元素是分散在不同的文件裏面，一些在模板裏面，一些在Java代碼裏或其它不同的地方。Spindle將這些統一了起來，在你編輯HTML的時候它可以自動從你的配置文件中獲取相應的信息而支持自動完成功能。你可以很方便管理這些關聯的元素，很方便在它們之間跳轉進行管理。更酷的是他本人也是一位Tapestry的使用者，他有他自己的Tapestry版本。當你進行修改保存時候它會自動在Tapestry裏面運行以便檢查錯誤，所以說它非常好。雖然Tapestry有非常非常好的runtime exception報告機制，我也確信他是目前最好的，但是你也不一定要用得上它。因爲Spindle在你保存文件的時候它就會幫你指正錯誤。因此開發人員使用Spindle，美工使用標誌的HTML編輯器，你需要的全部工具就都有了。
一些開發人員和設計師對URL方面有些抱怨，你是怎麼看待這些意見的？（譯者補充：Tapestry目前版本所有的URL都是框架生成的，用戶無法干預。）
我一直對這個都比較慎重。我所做過的所有程序從URL方面來說它們都不是那麼重要。我從來沒做過一個應用使用J2EE的基於URL的安全機制。因此直到現在我認爲這個問題不是很高優先級要做，Tapestry生成的長串的URL機制並不是什麼大問題。不過當我們的用戶基數增長時候，當更多人使用他的時候，項目的一些開發貢獻者象Eric Hatcher確實說過我們應該更好的來處理URL的問題。它將會是Tapestry 3.1的關注焦點，我們現在也正在忙這個。
至於3.0版嘛，呵呵，你還得忍受這種難看的URL。
Tapestry 3.0 final 版本有什麼新內容呢？
和上一個版本，就是還是在SourceForge的Tapestry 2.3相比較，有什麼新內容呢？首先是License改變了，使用了Apache的License ASL 2.0。我們的項目轉到了Jakarta，大量新的開發貢獻者加入項目，令人振奮。從特性方面來說，大的來講就是在2.3版中是比較結構化的設計，所有的配置都放在一個叫application specification的配置文件裏面，然後在這個文件裏面每個頁面有它自己的一段。但是新版Tapestry每個頁面都有一個自己的XML配置文件，我們稱爲page specification。在HTML模板裏面，你只需要引用這些控件，然後在page specification裏面配置好這個控件的類型，參數以及其它信息。所以新的開發者很快就可以用Tapestry上手，他只要添加一個HTML模板，一個page specification文件和一個Java文件就可以工作了，甚至你還可以用Spindle插件節省很多工作。另外一個Tapestry 3.0的重大改進是我所講的隱含控件，這種控件你只需要寫在HTML模板裏面，有點象JSP，可以把類型，參數等設置信息都寫在HTML模板裏面，因此連page specification都不用寫了，至少對於這個控件你不用寫page specification。所以配置起來更簡單，在模板裏面就可以看到所有的東西。我在我的書中幾乎都是用這種隱式的方法示例，因爲看起來更直觀。而且更酷的是你可以自行選擇用哪種方法（顯式或隱式），即使同一個頁面中你可以混合使用兩種方法。因此它是Tapestry 3.0的主要特性。另外新版當然增加了很多有用的控件。如我最愛用的是那個日期選擇的控件，它是一個漂亮的基於Java Script的下拉日期選擇控件。至於那些極大提高效率的功能，除了隱式控件，RAD樣式之外，那就是我強調的exception報告機制。它的由來說來話長，我曾在郵件列表上收到個一個埋怨，大致就是說“當Tapestry報錯的時候可以看到一大堆垃圾信息，能不能直接告訴我是配置文件哪一行引起出錯的呢”，我當時回信說這個要求太離譜了，因爲沒辦法可以做到這樣。但是兩週過後我又看了一遍這個郵件覺得這個提議還是可行。因爲每一步操作，如讀取配置和模板，它創建對象，它可以一直跟蹤回去，然後確定究竟是哪一行配置創建了一個對象。所以在運行期間，它確實可以將這些信息提供出來。如它可以告訴你Home.HTML 13行或者其他什麼地方有錯誤。當我在寫書調試我的示例程序時候也得益這個功能，當出錯時候我不用一行行去查錯，弄清楚究竟是哪裏出錯了。我再想想3.0版有哪些新東西……對了，我們有大量改進的文檔。我們編寫了很多文檔，增加了很多特性以及控件參考手冊，我們還將會提供更多的文檔。
你在這個精確錯誤報告的功能上花了多少時間？有多大的工作量？
我們來聊聊Tiles吧，Tapestry有沒有一個類似Tiles功能的地方？它是不是需要一個這樣的東西？
Tapestry沒有類似Tiles的東西，因爲它不需要。Tapestry是基於控件的。頁面本身也是控件，可以由控件來創建，和JSP不同，Tapestry控件可以有它自己的HTML模板。而且它們是智能的。
對於一個Struts開發者開始用Tapestry最大的觀念轉變是什麼？
有很多使用Tapestry的用戶都是由Struts過來的，甚至有WebWork的經歷。他們會在Tapestry裏面尋找他們熟悉的那些東西，可能會問“如何將URL映射到Action裏面”？當然你並不需要做這個，Tapestry已經幫你搞定了。你需要建立的意識是，你有了頁面，有了控件，有了後臺的操作，剩下你要做的僅是完成Java代碼裏面一個供框架調用的方法。許多人經常問如何才能訪問Servlet API，雖然這也是可以訪問的，但你完全沒必要這樣做。如果你想在在服務器端保存數據，你可以存在頁面的屬性裏面，然後讓屬性保存即可。Tapestry自己會管理如何在HTTP session中保存和傳遞這些數據。因此在這個方面，如果你尋找你期望那些東西他們完全是不同的東西。我仍然不能理解爲什麼大家還要在Tapestry裏面要這個，當你學會了那些煩瑣的東西之後你需要做的是忘記掉那些在Servlet，Struts中折磨你的東西，不要在Tapestry裏面繼續了。
Tapestry即將添加的功能有哪些？
如上所講，管理URL將越來越重要。現在你要是觀察一個有數百個頁面的真正的Tapestry的大型應用
爲了發揮HiveMind的優勢，Tapestry實際上已經進行了重構。HiveMind是我另外開發的一個微內核的service框架。
還有很多其他大家感興趣的特性。在WIKI上有一個長久的討論。如3.1版應該怎麼搞啊，3.1版是不是又要象3.0版一樣搞個一年半，還是說6個月就搞完，要添加哪些，幹掉哪些。很多人都有很多好主意。這些都在Jakarta的WIKI上，大家對發展有興趣可以去看看。
如何讓Tapestry 和Spring，Hibernate以及其它一些持久容器一起工作？
大家確實喜歡Tapestry和Hibernate結合工作，在過去的一年到一年半的時間做了大量工作。我意思是說有人做了幾個不同版本使用Tapestry + Hibernate的PetStore。我自己也在學習Hibernate。我想很多人都只用到了J2EE的小部分功能，因此他們希望有輕量級的方案。他們可能有一個Tomcat或Jetty再加上Tapestry和Hibernate，它們之間可能用到Spring或HiveMind。Spring有很好的Hibernate支持，當然從Tapestry的頁面也很容易訪問，因爲Tapestry的頁面是真正的Java對象不是腳本。當然整個來說Tapestry是表現層，因此你可以自由選擇持久層的方案，用Hibernate或是什麼，應用服務器也可以自由選擇Jboss，BEA WebLogic等。然後將它們放在一起。人們高興的是可以自由選擇喜歡的東西然後把它們組合起來工作。
能不能給我們介紹一下HiveMind以及它的由來？
HiveMind主要從三個地方成長起來的。當我在WebCT工作的時候，它有一個叫Vista的大項目，Vista是一個企業級的教育培訓軟件，因此非常非常大，有上千個Java頁面和JSP頁面。我很少碰到過象這樣的大項目，因此當然對在這裏的所有項目很感興趣。項目要求緊迫的進度，開發團隊也分佈在印度、麻省、溫哥華、英屬哥倫比亞幾個不同的地方。因此項目包含很多東西，沒有哪一個人真正瞭解Vista項目的全部進行狀態。但我有幸見識了項目不少的方面。項目中需要在某些方面做一些重構的工作，並且初期就在如何合理化啓動和停止方面預留了接口，因爲它在BEA WebLogic上面運行，有很多工具在一起工作，每個工具都需要在啓動的時候做一些特殊的工作，打開數據庫表緩存一些數據、或者是建立一個JMS連接等類似的事情。我曾經致力提出應當建立一個微內核來做這些事情，而不是每個地方都來寫一段Java代碼。他們在碰到確實需要一個類似HiveMind這樣的工具來處理啓動和停止功能時候也給了我一點動力。因此我就爲這個目的開發了HiveMind，而且HiveMind的想法是成爲Eclipse plug-in API一部分，你有一個微內核，它知道如何來從plug-in中合併各個元素。現在Eclispe的tools裏面，他們的plug-in API是
你能使用HiveMind進行配置工作嗎？
當然，這就是它的主要功能。HiveMind的主要目的是配置你的應用
講得好。當前Java中哪方面的技術令你比較興奮？
Java方面很多都在進行。我想我最期望的是Java的註釋（annotation）功能，它將會給類似Tapestry和HiveMind這樣的Framework帶來某些改變。所以你看到現在有很多有趣的工具在做這樣的事。但我認爲我喜歡Java的一點是它象其他一些語言如PL1和Object C，已經工作得夠好了。我想有一種理論是今天我們碰到的所有問題，都可以用一種新的語言來彌補它沒有的一兩種特性。我們以前見過，或許過去的更現實一些。相對Java來說，你不能具有garbage collection功能，如C語言一樣。這些將限制你構建的應用的複雜程度。我依舊認爲Java在服務器端已經做得夠好了，雖然我也對其他一些語言感興趣，如Groovy。我喜歡腳本語言的理念如Groovy和Python。我不想爲了一兩個新的特性放棄掉現有的東西，那意味又要重新完成這些煩躁的工作，又要去考慮初始化，配置以及連接等等。因此我認爲Java就是一個用來構建強大方案的肥沃土壤，完全沒有必要去追求另外一種神奇的語言，然後推倒所有的現有資源重來。另外我想談的是，我認爲Groovy確實非常迷人，或許當它穩定以後可以考慮在Tapestry裏面一些合適的地方使用它。
你希望看到JCP改進嗎？
當然。在我眼裏JCP是有點問題。如果你仔細觀察JSF一下如我參與的一個JSR－JSF，漫長的前期時間，結果所期望無條件相信，JSF是否能工作，是否具有擴充性，能否處理一些現實中存在的真實的複雜應用。我想我們真的需要一行一行去讀RI(參考實現)才能知道.