瓷砖的页面方案-- n个action凑一个页面。

多看看别人怎么做的

区别就是：我根本不需要portlet，也不需要去学习portlet。

今天用了Chain来实现，有两个问题：

1. 修改页面得修改Chain(添加的时候），比较讨厌。
2. Chain无法避免命名冲突，A叫了content,B就不能有content 。

相比之下，原方案：

1.与chain无关 2.与命名无关. 3.位置透明 5个request的代价是部署位置可变更。

此外都是本机的request不知道影响是否很大？

没用过chain，粗略的看了一下文档，猜想aciton用于chain中和单独使用需要定义两套。
你的原方案，5个request都是本机的request，意思是客户端发起呢，还是服务端模拟发起的？

服务器模拟发起的，我刚才做了修改，变成localhost不发起request而是去invoke action，remote则发起request,这样似乎更适合组件的分开部署，比如相片组件，可以部署在另一台服务器上，而服务器只请求了需要的html，并不牵涉照片的下载，实际下载还是由照片服务器来完成的。

你这种方式带来的问题比得到的好处多得多。服务器模拟最初客户的请求头，将信息聚合之后一起呈现给客户，一个是要解决耦合的问题，一个是实际的性能并不比由客户端直接发出多个请求来得低。

再，如果某个widget有脚本，你在服务端解析么？

服务端信息组装，比如struts的actionchain+valuestack，再比如tapestry4的组件（单独负责数据获取和模板渲染），都需要一个总的action/page来负责。

总的感觉是这些全在服务端来处理，有很大的应用局限性。

另，相关联的主题，好像前端时间robbin他们讨论过，具体的给忘了，好像是google的open social？

所以我加了invoke action的实现，这样就不在需要那个action chain了，可以作为同一服务器的一种选择来保持弹性。

此外我有考虑在"local","remote"两种选择中，再加入ajax，服务器只管组装脚本参数，实际完成交给client.