Web表示层框架主流解决方案：Tapestry
Web层框架分为Rich Client和Thin Client两类思路，下面分别分析：
一、Rich Client
Rich Client的关注者有很多，例如dlee、gigix、Quake。
dlee支持XMLHTTP，gigix的blog上看到他准备写一个“Return of Rich Client”，似乎有支持的倾向，Quake比较关注Flex。
当前Rich Client框架解决方案主要有几类，一类是XMLHTTP的解决方案，一类是基于Javascript的解决方案，例如Bindow，一类是Flex之 类的方案，还有一些用java web start的。我可以这样断定，当前的这些Rich Client没有一个有希望成为主流Web解决方案！
当前的Rich Client方案具有如下的缺点：
1、技术过于复杂，实现很不容易
2、不能单独构成一个完整的解决方案，还需要其他很多技术配合完成
这样就算你掌握了这种技术，仍然不能够把整个Web层做出来，还需要掌握其他很多相配合的技术，然后整合一个Web层的完整框架出来。
dlee公司做了那么久积累，自己公司已经形成了完善的围绕XMLHTTP的Web层框架了，但是其他公司没有办法模仿出来，现在也没有人做一个完 善的XMLHTTP框架出来给大家用，不是每一个公司都肯下功夫自己去钻研和围绕XMLHTTP去建立一个框架，并且这种框架也可能并不完全通用。
综上所述，当前的Rich Client框架更适合于特定的公司围绕该技术形成了自己独特的Web层解决方案，而没有可能成为行业的主流Web框架。
这里有一个例外，有人提到Longhorn的XAML，我承认我也看好这个东西，不过Longhorn要2006年才出来，普及还需要至少两年(不 要忘记2001年WindowsXP出来，到现在WindowsXP的普及率只有30%)，最乐观估计，XAML的普及也要到4-5年之后了。至于那个时 候XAML是否真的成功，还是未知数，不要忘记MS的hailstorm失败之惨。
二、Thin Client
Thin Client中流派也特别多，各种各样的框架，我都眼花缭乱了。有Struts，Webwork2，Velocity，JSF，JSTL， Turbine，Tapestry，。。。。。。这许多Thin Client框架中，我没有一个熟悉的，除了Struts之外，全部没有用过。所以且容忍我的厥辞和错误。
首先谈谈我唯一用过的Struts。我非常反感Struts，反感Struts僵化的ActionForm，反感Struts的死板的MVC结构，当然最反感的是Struts的Taglib！特别是html tag，这东西一用上，DW里面打开什么都看不到。
接着说Webwork2，这东西现在很多人对它好评，我简单看了看介绍，看起来似乎是和Struts一类的框架，只不过各个方面都全面的改良。
其他的我就更加不熟悉了，不过他们有一个共同的地方，就是统统喜欢用Taglib，而Taglib是我最讨厌，最反感的东西。
我认为JSP里面使用Tag，就是一个错误！我反对在JSP里面使用Tag，我推荐大家在JSP里面写Java代码，没错，就是在JSP里面写Java代码，我就是一直这么干！
很多人可能要跳起来批评我的反动了，我承认我的观点是让太多人不可思议，仿佛是历史潮流的倒退。但是我请大家想想看，JSP本质上是什么东西？
JSP是嵌入式脚本，是服务器端页面编程语言，没错，就是脚本语言，是页面编程，就是要你嵌入代码的。JSP为什么要出现，PHP为什么要出现，就是因为在页面里面嵌入代码很方便，开发方便，调试方便，连美工做页面都方便。
为什么PHP这么流行？就是因为在页面里面嵌入代码简单，开发非常简单！而且在DW里面，你写代码完全不影响美工调整页面，可以很好的分工。美工也不会吃饱了撑的去动你用<>括起来的代码段。虽然在一个文件里面，大家分工良好，合作愉快。
而且调试还很方便， 你随便一个out.println(..)，然后刷一下页面，看看浏览器页面上有什么结果，多方便。
然后看看JSP的Tag给我们带来了什么，nightmare ！美工mm用DW打开页面，看到的是一片空白，或者支离破碎的页面，她就纳闷为什么看起来好好的页面怎么就这样子呢？不应该啊！而我们的程序员gg也很努力的写着让美工mm看起来似乎很亲切的仿佛想html一样的tag，而不得不努力在后台做着tag的映射xml文件和编写麻烦的tag程序，极大的增加了JSP页面的调试难度，结果却是被mm扁。
有人说了，很多页面显示的重复性工作，你用Tag可以节省页面代码量，那我写Java class不一样吗，然后你在JSP里面调用Java class好了，tag本质上就是java class，有什么区别，就是调用形式不同而已。还生搬硬造了一套既不讨好美工mm的，又让程序员gg别扭的Tag语法，此语法还四不像，好像像 HTML，又不像，好像像java bean，可也不对味。最过分的是每个Web框架还自己搞一套Taglib，JSP2.0还增加更多的Taglib，我看除了把我们的程序员gg当猴耍之 外，没有任何好处。
如果Taglib真能实现页面和代码分离的话，他还总算有点可取之处，然而它根本没有做到，你仍然不得不在JSP里面去写点Java代码，你仍然不 得不在Tag程序里面写点out.println(...)，来输出页面内容，既然你做不到分离，那么藕断丝连的，何必矫揉造作的分开呢？增加了我们程序 员gg的负担不说，还让我们的美工mm在DW里面面对一些支离破碎的页面无从下手。Taglib，你罪莫大焉！
从Sun在JSP里面引入Taglib，我就认为他是一个谎言！我认为大家都被Sun欺骗了，我做JSP编程，但凡我写过的JSP，我从来不用 Tag，我觉得写java代码让我很舒服，我不需要再去学习那别扭而无意义的Tag语法，来增加我的工作量，来增加我的JSP页面调试难度。
因此，一切采用Taglib的Web框架，被我毫不留情的排除！然后我的目光落在了一个叫做Tapestry的东东上。然后我发现这东东有点像去年 的此时的Hibernate，仿佛一个地下幽灵，很多人都开始悄悄的讨论他了，并且得到了广泛的好评，但是还没有真正走上台面来被广泛的应用。据说 Tapestry真正实现了页面和代码的分离，并且把OO编程执著的贯彻到了Web层。
dotnet的webforms一出来，让我们大家见识到页面的事件驱动编程模型，算了开阔了思路了，然而webforms频繁的服务端交互也让人 很烦躁，webforms也是用tag方式来定义服务器端组件，通过hidden 域和服务器交互，不适合Internet，只不过MS自己的工具FrontPage自家可以读出来这样的Tag，所以webforms还是在用tag，但 是他向我们证明了一点，OO是可以贯彻到Web层的。
我想要的就是一个可以页面和代码完全分离，不需要使用Tag的Web框架，能够OO当然最好，我似乎隐约的预感到Tapestry是我心目当中真正要的Web框架，他有成为Web框架主流的可能性吗？我不知道，但我已经对它产生了兴趣，我要研究研究它了。
噢，对了，还有一个JSF，Sun的JSF，不过我眼中已经没有Sun了，这几年来，sun都干了些什么？就像我们不能指望JDO2.0一样，我们同样不能指望JSF。