Tapestry之我見

最近在研究Tapestry4，而Tapestry5也在如火如荼的開發中，年內應該就可以release了吧！
Tapestry5對整個架構完全重構，現在的tapestry5吸取了許多其他優秀項目的優點，包括RoR和google的guice。

看到過正面的評價，如：“apestry這樣面向組件的web架構確實顛覆了我所有關於web架構的經驗。
”
當然也有反面的評價，如：“最討厭代碼和注釋功能混在一起，從來不覺得這是進步”； “儘管不喜歡tapestry的page設定檔，然而更討厭annotation的一窩蜂的亂用，把配置和代碼邏輯寫在一起一鍋亂燉，想要改個驗證條件還得重新寫class檔案。
HWL思路開發的tapestry架構最不好的地方就是無論模板、驗證、IoC、各種頁面組件、session管理、上傳下載等什麼都要自己作， 別人現成的優秀架構不容易整合進tapestry，開放型和互動性不好。我覺得tapestry裡學了不白學的似乎只有ognl語言了，這個還不是HWL 開發的。
相比只下spring的開發思路就很好好，不要重複發明輪子，只考慮怎樣更好的使用它。貌似T5裡這種開發思路沒有根本性的改變，打算從T4轉到S2或WW，繼續觀望T5、T6。”

然而，有的時候就是需要重新發明輪子，正像如下所說：“現有的解決方案即使再不好，因為已經積累了大量的代碼，開發效率仍然比從零開始的新的解決方案更高。如果我們只關注軟體所能提供的商業價值，可能我 們永遠都只會使用現成的東西，而不會另起爐灶做另外一套東西出來。以前 potian 批評 SAP 的設計已經落後了，與對象建模完全格格不入。這樣的批評也許是正確的，但是想想看你如何才能積累到 SAP 這樣的代碼量？現在實現相同的業務是基於 SAP 更容易還是基於你們自己的 ERPTAO 更容易？萬一是一種你們從來沒有想到過的商務程序呢？

不過反過來說，如果大家都只從這個角度來考慮問題，那麼技術就永遠都不會發展了。而落後的架構從長遠看所能提供的商業價值也是有限的。例如在 SAP 之上實現 OLAP 一類的分析的成本是非常高的，原因就是 SAP 的基礎資料庫設計完全沒有考慮過分析型應用。所以我的朋友 xel 說：“有時候就是要重新發明輪子！”

總之，我認為Tapestry也許不是最順暢的道路，但絕對是一個可取的道路。

讓我們更自由的進行web開發吧。