Spring BeanDoc
从Howard的Blog上得到的消息，改善了XSLT的HiveDoc已经比较漂亮了：
http://jakarta.apache.org/hivemind/hivedocs/index.html
但是，遗憾的是，就是这种界面也不觉得有多漂亮。我在HiveMind初探中提及，HiveDoc是Hivemind比Spring有优势的地方之一，这种优势已经不复存在，BeanDoc生成了更漂亮的文档，相比HiveDoc而言，BeanDoc在组件之间的关系上进行了更清晰的描述。
BeanDoc描述的JPetStore: http://springframework.sourceforge.net/beandoc/jpetstore/
petClinic: http://springframework.sourceforge.net/beandoc/petclinic/
How many web frameworks now
Echo
Cocoon
Millstone
OXF
Struts
SOFIA
Tapestry
WebWork
RIFE
Spring MVC
Canyamo
Maverick
JPublish
JATO
Folium
Jucas
Verge
Niggle
Bishop
Barracuda
Action Framework
Shocks
TeaServlet
wingS
Expresso
Bento
jStatemachine
jZonic
OpenEmcee
Turbine
Scope
Warfare
JWAA
Jaffa
Jacquard
Macaw
Smile
MyFaces
Chiba
JBanana
Jeenius
JWarp
Genie
Melati
Dovetail
Cameleon
JFormular
Xoplon
Japple
Helma
Dinamica
WebOnSwing
Nacho
[...]
为什么Bindows不会成功
Bindows(http://www.bindows.net)新版本1.30beta出来了，增加了千呼万唤的Theme支持。Erik&Emil不愧为世界水平的JavaScript高手，原本仅用做浏览器脚本支持的这个小东西如今被发挥得淋漓尽致，几乎到了浏览器JavaScript所能表现的最高境界。看过的人几乎都会叹为观止。观止观止，观而止，这一点上，客户似乎与开发者保持同样的态度。
无论从Bindows的站点，还是其论坛，还是Google的搜索结果，对Bindows的感觉几乎停留在这样一个感觉层次：技术好，速度慢，至今没有商业案例。更有甚者，评价其为“C/S的回归”。回归意味着什么？对于开发者而言——呃，我一直将开发者置于比客户低的地位——，除了恢复原来的编程概念、方法、模式，照拿工资，几乎没有什么改变。技术的变革从来不是以开发者的利益作为第一位的。而对于客户，这种回归却是不可接受的。
ChinaUI(http://www.chinaui.com)上每天都有新的设计作品产生，有相当大的数量集中在B/S系统的产品上。B/S给软件开发带来巨大改变，但与此同时进行改变的是用户的审美品位的提高。你无法再将windows经典的窗体颜色应用到绝大多数Web应用中，美工开始变得重要。客户口味越来越奇怪，很多时候一个项目的交付被卡在美工上，客户喋喋不休的说这个颜色/那个颜色不喜欢。从国内外已经出现的软件界面设计公司，可以看到这样一个趋势：用户对软件的需求已经不仅仅满足于实现功能，对软件的体验开始变得同样重要。回忆一下，《冒牌天神》中发邮件的界面，一些电影中显示人员档案的界面，《黑衣人》中的海关电脑界面。随着软件的发展，这些界面相信也会出现在实际的软件中。
RIA应运而生。Macromedia公司的Flex(http://www.macromedia.com/software/flex)，开源的Leszlo(http://www.openlaszlo.org)，都是这方面的代表。Flash经过多年的发展，已经从典型的动画格式开始向着一种用户友好的表现形式发展。从Macromedia官方公布的资料看来，已经有一些成功的商业应用采用了Flex，用户体验相当好。而从我给一些客户演示laszlo的实例来看，Laszlo“增加了对Web应用的期待”。这种期待显然是界面、操作感觉的期待。RIA, Rich Internet Application, 在我看来一个最为体贴的解释就是“丰富客户体验的Web应用”。Rich在这里，所指并不仅仅是提供开发者丰富的控件，更重要的是给客户丰富友好的体验。
Bindows所做的，从第一眼看上去，就象是所有windows控件的模拟。按钮，标签，列表，文本框，对话框，颜色，样式，等等，一个典型桌面应用应该有的控件、样式都具备了。客观的说，用JavaScript实现这些并不容易，作者花了整整两年时间，这个产品还在继续维护。为什么至今没有商业应用（据我所了解，没有）愿意采用Bindows呢？我分析：Bindows不能成功也不会成功的根本原因在于，它意味着用户体验的倒退。换句话说，这是一个开发人员一厢情愿的产品，丝毫没有考虑到用户操作感觉。如果这是一个彻底的桌面程序框架，融入到传统桌面程序的大潮中，那么也许还有成功的可能；但是这个产品定位于运行在浏览器中，是Web程序，没有用户愿意看着别人能够在浏览器里进行丰富多彩的操作，而自己只能对着灰蒙蒙的屏幕。当然，在我所未知特定行业里面或者用户操作计算机层次不高的情况下，用户体验也许不重要；但是随着时间的发展，这一点会逐渐消除。毕竟，没有人会拒绝美丽。
AMOWA: 不应该关注URL的形式
除非是内容相关的系统，如CMS, Blog, 新闻，门户，论坛，网站系统等，这些系统需要一个明确的链接，来指引用户进行直接有效的访问。但是企业应用系统往往对这些并不关心。例如一个信息管理系统，几乎没有人关心浏览器地址栏里面的链接组织形式，除非一些别有用心的用户。
把握这一点很重要——我是指进行一个Amowa的实现。在我去年提出观点中，我指出，amowa不适合内容相关的系统。虽然这么说，但是当我试图实现一个amowa思想的论坛时，URL相关的东西让我头痛不已。一方面，既然是改善客户体验，所有的操作采取无刷新的方式来进行，那么用户从浏览器中看到的就只有一个地址；而另一方面，用户也许需要对某一贴进行引用转贴时，需要知道类似与thread?id=123的东东。这个问题困扰了我很久，项目也迟迟未动工。
在参与现在的这个商业项目中，我注意到用户根本不关心链接的组织形式，特别是系统非常庞大，页面采用框架进行组织时，浏览器中地址从来都只有一个。操作的感觉就像原来的VB/Delphi时代的C/S软件一样。这么说来，对于操作/功能型的系统，URL并不重要，那么这个时候amowa的各种威力就发挥出来了。
下面附上这段时间思考的Amowa框架目标，希望对有志于amowa框架开发的同仁有些启发：
采用纯粹HTML作为界面描述语言，减少学习梯度。只要学习HTML便可编写WEB界面。
利用XMLHTTP或者其他访问方式来进行远程访问/调用，减少带宽要求
一致性对待客户端与服务器端。对页面开发者而言，他看不到服务器端；对服务器端而言，他看不到客户端。两者完完全全的独立开来。
服务器端控制页面流转，非常简单的方式进行页面跳转，客户端被翻译为正确的JavaScript调用，从而让客户感觉更好。
客户端缓存。客户端访问得来的页面内容，被缓存到客户端，下次访问非常非常快。
丰富的客户端组件