可执行XUL:Fabulator

相信在大多同人眼里，laszlo已经足够另类以至于不容易接受。
怀着ajax梦想的人们又在苦苦寻找和等待服务器端或者客户端的解决方案。

（瞧瞧我带来什么，哈哈）
今天早上开机，一个程序通知我它需要更新3.0，于是我连上去了，“换主儿了！”
原来，Yahoo!把这个东东(Konfabulator)彻底并掉了，刚巧我昨天点过"check for updates"没东西，今天自动提醒我，估计就是今天了。

嗯，来头不小，yahoo的map,mail,notepad,calendar统统在上边，下午查了api以后，居然还有一个yahooLogin()方法，后话了。
论坛上赫然写着ajax的大名，于是我down下reference来看。
它，
不同于xaml，他不需要directX或者.net framework支持，它是一个驻留的动态运行库（限win/mac平台）；
不同于xul，他不需要浏览器支持，他貌似一个纯客户端程序；
不同于lzx,mxml，他不需要服务器运行环境；
不同于flash ria，它不是一个bin。

细想起来，ajax好像没有限定必须在浏览器里边。而他已经有2个年头了。

熟悉任何一种xul语言的人，可以轻松上手。
javascript我粗略看了一遍，是很广范的，有try catch，xmlHttpRequest，DOM API，xpath也是直接用的。

你下到的.widgets文件其实就是一个zip，他把.kon和一堆js，图片包在一起。你可以直接运行里边的.kon文件。

http://widgets.yahoo.com/gallery/
有1500多个别人写好的开源代码可以让你学习。

在xaml时代未来临之前（如果会来的话），那它是我见到的最酷的ajax了。

没有浏览器，多了一个驻留程序，其实也没啥好炫耀的，但好处在我眼中远大于此弊病：
1，大多数ajax应用苦于受到浏览器限制，不光是语法，后退、刷新按钮，还有有些应用不希望用户最小化，或者及时通知用户等等高级交互特性，浏览器在底 下闪啊闪的没人看到，而且，占用内存一般在50~100M，公司做的那个我是一般不去的。这个1M左右的程序大约也只有8M内存占用。
2，计算机API，有部分的Windows/Mac api包含在内，据我所知还有iTune的api。
3，插件机制 所有widgets运行于这个驻留程序，而他，其实是一个eclipse一样的东东，可以从他管理之上的windgets，包括你刚写的。好处是什么不言而喻了吧。一个庞大的系统可以被拆开来，甚至按照用户自己的意愿随意组合。
4，即使不做ajax应用，做一个客户端程序，写laszlo的话还要跑tomcat，还要打开浏览器，这个则不用，自己做做小游戏自娱自乐也再好不过。

LaszloMail启示录

上上个星期吧，laszlo终于拿出了他规划中的第一个public应用laszlomail。

试用了一下他的所有功能，欣喜70%，失望30%

然后推荐给了几个朋友，自己也就不再用了。

在我突然有了想把A项目做成一个独立的应用，准备加入登录机制时，我又一次去研究了laszlomail。

它有几个很值得学习的地方：

1. 上传下载文件是我一直觉得laszlo能力欠缺的地方，它做到了
2. contact中的人的那个item上边包含了若干按钮，使用普通方法写不出的，它做到了
3. 登录时通过cookie，并且整个项目的载入方式很值得研究
4. laszlomail能根据窗体的大小变化而变化，比如缩窄到一定程度按钮上的字没有了，很cool

缺点主要是网页没有支持xhtml1.0规范。我花了一点时间在A项目上仿照出其加载方式。

让我震撼的是，我一直自认为javascript厉害，但其实只是laszlo中的js，浏览器上的一干方面都是几乎空白。

就好像我前几天翻出了我3月份给别的项目做的一个'登录'一样，当时的'好作品'在今天看来却几乎都是要重写的了。

我写程序的原则，是要让我自己1年后再看的时候能很容易得看明白

不过这也没啥不好的，这说明我在进步，发现以前写得越差越好。而且，我也找到了前进的方向

aszlo让我喜欢的是因为它的界定和封装恰好是正确的ajax，它的tag没有违反任意扩展的原则，而且，这个封装提供了不多不少的一个解决方案，比起用上一串名字做出的一个ajax要好得多。

缺点是flash输出，偶尔会有的性能问题。

嗯……就flash输出而言，其实好处还是大大的

• bin形式（很大程度上）避免了别人hack
• 是一种压缩格式，减小流量
• 封装了脚本语言的支持，完全不用顾及载体，哪怕是手机也好

这三点也有相反的表达：

• 阻碍了开源项目的进步，无法传播源文件（其实你改一下lps/config也行，不过作为发布中的项目……- -!）
• 延迟加载变得比较难写
• 本身无法限制输出平台

LaszloMail的license貌似还在研究当中，反正就算有源代码也不容易拿到。

想学也不给机会……？

刚刚在查找他们的license时找到了这个

http://weblog.openlaszlo.org/

很有意思，他们居然也用wp。

另外有意思的是这篇Ruby the Rival

Wasting time on Laszlo

我上次在laszlo论坛上说了我解决memory leak方法，一个美国人建议我用laszlo3.1，它解决了大部分潜在的memory leak，我用了，的确比我自己写的还要好，但是随之来的是我以前的很多功能失去了期望的表现……

如何通信(2)

我所说的1和2的结合，就是全文比较和包含元操作的队列同步地结合，从服务器获得全文，在客户端merge，反方向则只用元操作的队列。

好处是可以保证服务器的version控制，需要重点考虑的还是merge的策略，目的是让客户端看不出来我正在同步中，至少不影响他的操作。

这样做似乎不需要写出一个cronExpression的js实现，减低了很多难度，而且符合了我eventItem和event是两个概念的需求。只需要同步的快点就行了。希望他在上不了网的时候少做一些什么重复性的设置。

队列，我的想法还是保存一个字符串的js数组，然后用反射去执行，队列不成功就不断重试好了

小有收获，实例化出来的两个queue竟然在使用同一个queue和remote，还没想明白为什么。这个attribute也没有final,static, transient让我选，可能是node的特殊性吧，为啥以前这么在view上就不会有这样的问题。所以，我干脆把他们做成两个node，反正他们的行 为和策略也不尽相同。

的确是很短小啊，我记得我当年写过一个connectionImpl，相应部分的java代码虽然严谨但是的确是非常难写的，我今天再看了一 次，那些notify然后到哪儿了我都说不清楚。不过感觉自己以前掌握的线程，锁，这些的应用还是很扎实的。嘿嘿（时隔一年就看不懂了)

为了在队列同步时尽量减少冗余的数据甚至频繁的远程访问，比如在summary上ontext的 时候希望更新currenteventDP，但是同样的会希望提交更改，可是这样的话每写一个字就多一个remotecall，即便是做出了负载平衡，但 是用户甚至保留页面至(操作数*interval)时间，简直十分荒唐。

所以我昨天添加了客户端产生uuid的方法，并且有了包装成js类送回服务器的通用包装类，这样的一个wrapEvent通过此uuid唯一认证，那么我更新了enqueue方法（见于上一entry）。splice掉了旧的还没有同步出去的内容。

如何通信(1)

今天的计划是让新建任务面板中的是否是未安排任务的checkbox可以和event对象互动。

这个题目要求event的托拽可以影响checkbox的value，而点击checkbox，event也会产生托拽的效果。

这我以前似乎做过，但是认为是无解的命题了，无法避免无限循环。

还是calendar，让我看到了正确的设计。

很简单，通过

可以得到是否托拽改变了category，再让onclick去改变这个值。我也想不起来为啥以前没解决了。仿佛还有lazyreplication的问题吧。

不过，我认为其文档是有错误的，文档中说path相当于once语义。谁晓得是个always语义。

客户端街面上的操作，基本上做成了（去掉重复性，给别人布置==以后），但是还没有数据通信，我考虑了一下午，一样无解。

我规定了几个前提：

• 用javarpc
• 实现异步
• 减少数据流量
• 基于timestamp的version控制

有三种通信方式的念头：

• 最蠢的和最简单的就是做全文比较，几秒钟用客户端数据和服务器比较一次，可以完全地做到异步，但是如何保证用户最后的操作也被异步同步了，呵呵……
• 纪录每一次元操作，用什么特殊语句或者对象记录一下，放入队列中，然后让队列做异步同步。这种方法如果操作与操作之间有耦合、冲突、先后性的话，那还不如第一种，再说如何记录和分析命令，也是会比较晦涩的
• 任何元操作都产生一个rpc命令，做完就做完了，这样在网络畅通的情况下可以保证客户端和服务器的数据一致性，也不用做什么比较和分析。如果不畅 通，有一个rpc没成功，那么两边就有分歧了。而且我刚刚在实践的时候，也发现，addEvent没办法简单保证立刻获得新丁的id，要么停滞下来等，要 么就得不到。不过这也是可以继续研究的，说不定有方法。

calendar源程序没有这一部分，但是做第一种的扩充是最简单的。

以前在"麦迪快"里，我用的是1和2地结合，把我折腾半死，当然，看起来还是不错的想法，只是中间问题多多。

烦！

10-20

event的颜色以及可以附加在上边的eventselector的颜色，是由\\event\category\@value控制的，我添加了一个然后添加了一个新的style，果然好用。

这一种做法，我曾经在3C的项目中使用过，不过那时候并没有根据服务器的数据作改变。

event的选择颜色的做法也是很值得我学习的，

var gColorTable = {
green:{
dim: 0xCBD1C5,
bright: 0xD4DAC8,
bkgnd: 0x587457,
trans: {ra:85, ga:100, ba:85}
},
blue:{
dim: 0xBBC6D1,
bright: 0xC6CEDC,
bkgnd: 0x4C5E7E,
trans: {ra:75, ga:85, ba:100},
bvl_bkgnd: 0xCDD4E0,
bvl_hilite: 0xDFE4EB,
bvl_shdw: 0x606369
},
....

}

var category_colors = {

holiday: "green",

astro: "purple",

....

}

下午从addEvent(cal-data.lzx#138)方法开始研究，在197行处的

alleventsDP.addNodeFromPointer(blankeventDP);

发现这句话的前后currenteventDP从无数据到有数据。甚是不解。currentventDP在这一个文件中没有setDatapath，setFromPointer之类的赋值方法，搜索所有文件也没有发现这三个pointer之见有什么直接关系。

搜索currenteventDP发现，在eventselector的setSelectedEvent方法中有一句

currenteventDP.setFromPointer( e.datapath );

debug一下，果然这句话在currenteventDP发生改变的时候起了作用，而这个方法正是event的selected属性的setter方法中使用的。

// When a event is current it's selected node attribute is 'true'
// This is the only way that an event becomes the current event,
// which in turn selects the event selector bar
debug.write("sel", sel);
this.selected = sel;
if (this.selected)
eventselector.setSelectedEvent(this, this.mouseIsDown);

而event和alleventsDP指向同样的数据源。

哈终于被我发现了来龙去脉，这样写保证了currenteventDP始终是那个被选中的event的dp。

10-19

昨天的问题已经通过过滤date而解决了，今天也实现了彻底的dnd，把应用在timeview上的vscrollbar也用在这上边了。

Z轴深度的问题还是没有解决，拖动的时候会让选中的event看起来跑到界外边，看起来很奇怪。

接下来想研究event.lzx，也许可以让event条看起来更生动。

我希望用颜色表示event的状态、类型、级别

日期的问题，我先前想错了，从服务器给客户端的只能是year,month,day,hour,min,sec几个值，这样做一方面可以很容易从xpath映射到对象上，不用中间写解析long值得问题，另一方面，假如某人设定了'8点中起床'的任务，不会因为时区改变而改变，变成NY的20点钟，etc,.

而另一种event也许是需要站在绝对时间的立场上考虑的，就是拿一个时刻点，不管你在那个时区，它离格林尼治时间就是那么多，这也是有可能的……

另一个更严重的问题是，如果服务器从中国搬到了美国，那么所有人的所有event都迟了或者遭了半天，……

所以我仍然有个想法是保存客户的timezone信息，而这个在我设计cronExpression的时候已经加进去了，后来还不知道是不是需要，如今看来是很需要的。

这样看来，用户的意念会有两种，相对的和绝对的，而绝对的需要知道设定此时间的确切时区或者timezoneOffset。

而客户请求的时候自然是要带着自身的timezone信息去请求的，如果是绝对的可以忽略此信息，而相对的就要使用此timezone耦合出用户需要的时间。

嗯……这样看似是可行的吧。那么需要决定这场计算的生命期，用户每秒钟绕地球7圈的话，哪一样是无解的命题。

要下班啦，明天想。

new Date(0)

向来只知道new Date(0)是1970年1月1日

今天在laszlo里写new Date(1970,0,1,0,0).getTime()却得到了-28800000的答案，一除，相差了8小时，心想这肯定是因为我们在+8时区了， 顿时很迷惑，到底该用new Date(0)还是new Date(1970,0,1,0,0)。

又在java里写了一个测试，果然，

Calendar cal = new GregorianCalendar();
cal.setTime(new Date(0));
assertEquals(1970, cal.get(Calendar.YEAR));
assertEquals(0, cal.get(Calendar.MONTH));
assertEquals(1, cal.get(Calendar.DAY_OF_MONTH));
assertEquals(8, cal.get(Calendar.HOUR_OF_DAY));
assertEquals(0, cal.getTimeInMillis());

Calendar cal2 = new GregorianCalendar(1970, 0, 1, 0, 0, 0);
assertEqual(0, cal2.getTimeInMillis() + cal2.get(Calendar.ZONE_OFFSE));

想想也对，Date是带着TimeZone信息的，而这个时间0点又不能因为地区的不同而有不同的含义，嗯……这下认识到了

在laszlo中的写法就是

var tempt=new Date(1970, 0, 1);
if (tempt.getTime()==tempt.getTimezoneOffset()*60000);

而我想，在我需要的这个地方还是用0比较好，而不是各个地区的"0"。

10-17

周一的早上是最最痛苦的，被拖着拽着起了床，到了办公室眼睛才睁开了30%

晨会上经理问我这周都做了啥，我又是要想好一阵，结果还是没有说全。

看来还是有必要记录一下

今天上午修正了buzzbar的两个错误，

1货主为空时编号dataset没有清空，2货主的datapath增加了排序特性，这样""在第一个了。

嗯，对了，还有一个错误，就是roll(Calendar.DATE_OF_MONTH,-31)的错误，如果小月的次月1日那就会跳过啦，一会儿改一下。

还修正了Ant脚本的一个错误，

关于用Ant作war->upload to ftp->telnet and restart tomcat，仿佛在服务器上执行有效率问题尤其是服务器的回响是中文的，在Ant上根本看不懂，于是在自己机器上写了一个 build_test.properties反复运行了几十次，应该是没问题了。改了xmxxms都到512，可能不会内存溢出了，再溢就是某某写的有问 题了

Event系统在开始重新阅读我自己写的代码，做了些重构，优化了一些在选择人物的时候的一些操作方式。

下午准备能研究一下dnd，保证datapath更新。

PersistentEnum

新项目自然要有新念头。

捧着上个月月初写下的UML类图，满头的问号，仿照Workflow做的Step，又是Privilege，Request上还画了一个1..1的自相关，最恐怖的要数MessageStrategy。唯一记得的，是花了N长时间弄得CronExpresstion。

先把UML重构一把，涂上醒目的颜色，心里清楚了一些，有两个族需要做subclass，可是又超过6个类是表示状态的Enum。

5分钟搞定类结构和hbm.xml，突然对PersistentEnum钟情起来，因为之前也是各处出现的这种东西要么就做成static final了，要么做成类型安全枚举了，有的还给出了ResouceBundle弄了些中文。但是，持久的一点花头都没有，int,String无出其右。写了那么多注释也对安全毫无帮助。

Hibernate2.1上

package net.sf.hibernate;

/**
* Implementors of PersistentEnum are enumerated types persisted to
* the database as SMALLINTs. As well as implementing toInt(),
* a PersistentEnum must also provide a static method with the
* signature:

*

* public static PersistentEnum fromInt(int i)
*
* @author Gavin King
* @deprecated Support for PersistentEnums will be removed in 2.2
*/
public interface PersistentEnum {
public int toInt();
}

reference上让这么用，但是明摆着不想让人用好，找了好一会儿，看javaeye去年也有人讨论这deprecate的方法怎么绕，UserType我以前也写过就是没写过Enum的，而且那次的记忆完全是灰色的。

找到了一篇hibernate上的doc， 改了一下，仿佛可用？

嗯……开始玩测试驱动吧，写了一个测试，run,run,...run.

去掉了发现的30来个错误，最后变绿了，哈哈

太好了，int,String这么缺乏表达力的东西终于可以说88了，而且这样写出的类型安全枚举十分的干净。不错不错

Laszlo Bug?

// Moves the current event to the next or previous day
// Assumes updateEventDate has fixed any incorrect start tag data
// Get current date info
var year = Number(currenteventDP.xpathQuery('start[1]/@year'));
var month = Number(currenteventDP.xpathQuery('start[1]/@month'));
var day = Number(currenteventDP.xpathQuery('start[1]/@day'));
var tempDate = new Date(year,month-1,day);
//Change day
tempDate = new Date(tempDate.valueOf() + whichWay * 86400000);
year = tempDate.getFullYear();
month = Number(tempDate.getMonth())+1;
day = tempDate.getDate();
moveEvent(year, month, day);
这段代码的原始形态见于cal-data.lzx的325行。原来的代码其实并没有太大的不同，但是在"今天=8月31日" 或者"今天=10月31日"的时候，滚动日期到下一天，再下一天时跳到第三个月。
比如10.31->11.1->12.2这个问题我在以前写了类似的代码时，也出现了。

今天看到如此熟悉的代码，我把系统时间改为10.31后，果然是这样。而我随便改了一下，甚至再改回去以后，都可以正常的工作。

Crawling

Otto最近对我格外的关注，我想，多半是因为看了我的演示吧。最近又是给我算命又是请我吃饭的。在他眼里，我势必可以在月底结束这个刚刚开始的无边无际的系统开发。嗯，到时候我的日子就不好过了吧。

我盯着上周阅读过的laszlo calendar的代码，我估计很可能结束在了cal-data.lzx这个部分。我怎么也想不起来什么时候看过了。

上周5，我仿佛是在重建CVS吧，

<为什么要做>因为更换lps中间件的工作每每会让CVS近乎瘫痪，每次都有1800个左右conflict的文件，而且每次去比 较着nk的不需要去比较的内容也是造成工作成员不愿意去频繁同步的原因。于是我把openlaszlo-*-servlet.war放在了项目里，又写上 了一段ant脚本，哈，自动分布就搞定了，可是需要调整好cvs才perfect。

<为什么要这么久>

我实在是不会把Version Control的东西再变成.cvsignore的，只好mstsc去改cvsroot里边的东西，好不容易折腾让我自己去同步项目的时候不会出现错误 了，另一个也频繁同步的同事可以成功同步，但是在其他并没有频繁同步的同事的上边就出现了问题。……折腾了后来的一个下午也没有搞定，决定等待一个稍有性 能的cvs服务器...

上周4，仿佛我也没有做我自己的工作，项目里到处出现的硬写在项目中的webapps的名字，我决心把他们都改掉。于是先开始简单学习了一下javascript的相关部分，于是写了一个小方法获得项目发布后的url

function baseUrl(){
var flag=0;
var baseRef=location.href;
for(var i=0;i<4;i++){
flag=baseRef.indexOf('/',flag+1);
}
return baseRef.substring(0, flag+1);
}

然后把原来确定不下来的相对地址 引用用document.write加上这个方法串起来就好了。这么简单的工作居然长久以来都没有人做，害得我每次因为必须把我的tomcat也要输出到 "triz-link"而非常的不爽。更重要的，是因为中间这个"-"带来了很多麻烦，我发现laszlo的右键菜单仿佛就会因为这个"-"而工作或者不 工作。

周三么，仿佛在研究这个laszlo的右键菜单，就是因为Otto一句话。

关于右键菜单，虽然现在搞定了应用的环境，但是我最终还是决定不使用它了，Flash就应该是只点左键的。尤其是手机上使用的时候未必可以支持到右键。也许和swf6,7,8也有关系。我可不想让我的东西这么挑剔。

那么，我上周只是用了2天时间来读代码吗？不，我仿佛是周1给他做的演示，演示完了就下班了。那么，难道是周2？周2好像Robbin来过，我记得Robbin来的时候我一直在玩Ajax的项目，meebo还有netvibers之类的。后来在学习Venkman吧……

AFLAX?

转眼就快10.1了，我仍然坐在我的位置上，不再考虑做laszlo的传教士，虽然那几个demo程序早已写好了。我不得不承认我极度缺乏对别人的耐心，并且更重要的是，我自己也没有完全的认识。

同事发来了meebo的网站，看过后甚为震惊。同时，通过它，找到了许多其它的ajax项目。

我很开心看到这样的技术如今铺天盖地的阵势，因为我觉得我也是体验以及应用这样的技术的一员。

在wikipedia上对ajax有很多的解释，而同时有一个字眼也映入眼帘：AFLAX。

开始困惑了。

ajax的概念在于在客户端多出一层专门做数据的传输和处理，而以Flash为基础的客户端技术本身就必须包含处理数据的这一层，而不是让服务器去产生业的代码，aflax的提法让人觉得十分得牵强。

我想不出不使用类似ajax概念的话如何使用flash，难道直接使用swf-lib.jar？

其实，ajax也只是RIA概念在html时代的绝唱而已。当然这样的开发手段在具有足够开发理论的今天，还是具有十分的划时代意义的，他让许 多html,xslt,dhtml,js的拥趸有了继续发展的可能。（webwork,spring-web,jsf,以及一堆有助于逻辑分离的工具在扮 演着同样意义的另一个角色）。

那么这种Aflax就是一种和ajax的对立咯，只是强调了客户端载体的不同。

可是，在我心里过滤的结果，答案更加的唯一了，那就是 Laszlo ！当然我认为它也属于一种A.+ax

Ajax:

• 仍然是一个概念，众组织给出了解决方案，但是极为不统一。
• 客户端变为更重要的编程对象，但是它的代码无法得到保护是一个问题，整理和理解在项目管理上是一个问题，需要面向n种不同的载体更加是一个问题。这些问题的结果就是：复杂度变高了
• 需要为了跨平台特性付出很多时间。

Laszlo:

• 是一个完整的独立的解决方案，可以方便的在任何已有项目中使用。
• 核心仍然是a.+ax，服务器程序不会因为客户端改变而改变（太大）。
• 封装了一套界面元素对象，和逻辑对象，有调试器和编辑器，可以使项目容易规范和扩大。虽然一样有动态语言的不利之处。
• 完全的跨平台，甚至是任何支持flashlite的手机。

起来倒了一杯水，忽然看见周围同事们正在做的flash客户端。

我才想见刚刚一文中有过于武断的言辞，那就是，用flash只能用xml交互不错，但是运用方法呢？

我相信Ajax中也包含了运用方法的信息，如果把大量的xml从服务器拿过来，自己在填充到客户端的组件中，每一次查询方式改变了，就又从服务器查一次，再填，……

这样完全抹杀了Ajax，多出来的那一层除了增加难度没有别的意义。

没错，同事们正在这么做，致力于把flash仅仅当做浏览器中的浏览器。

所以我再多一个断言，Ajax必然包含一组恰当应用的理念

这样想来，Aflax的确是有他的意义了。

不过，这样的断言正确么？

用Laszlo一样可以写出来这样的坏味道，而且我可以随手就写出来这样的例子。一项语言是无法避免别人是如何去使用它的。所以如果断言正确，我应该写的是ALAX吧

运动开始

不知不觉新工作已经两个月了。
RIA在冲击着人们的大脑，反思了，认为flashRIA不好；成熟了，认为Ajax和FlashRIA各有利弊。我依然要维护我钟爱的Laszlo，不仅仅是因为他开源，更因为它的架构像一碗清水。老板认为再清楚不过的东西你们怎么还做不出，可是一连串的开会才让他认识到从来也没有谈到某些问题。系统没有人去架构，每个人都在单挑。我说话没有分量。6月7日，拍板决定我仍然是用Laszlo来做。能让我发挥我的能量，我感到十分感激。
这两个星期是小有成就的，至少robbin和otto没有表示不满。javaeye上发表了一些厥词，附和了老庄的OO远去的一些观点。 OO只是描述世界的一种方法，最plain的方法，而要硬要把编程的思想固定在其上，就反而会变成一种难于适应一般的思想。OO这样的写法适合具有层次的逻辑清晰的极具灵活性的东西，所以服务器方面是十分合适的OO这样的写法并不适合描述一干事物之间的联系，在RIA中尤其显然，我的需求就是一些事物的互动。好吧，Laszlo本身也说自己是OO的，不错，是的，是用O来描述，要我说，这种应用程序有两个灵魂对象族:Events和States。我需要的是全神贯注的描述事件的内容和发生的时机。eclipse的SWT实现应该算不错了吧，你可以去看看他的实现过程，可以说这一部分依然是完全的耦合的，到处传递的Runnable对象，可怖的充满着反射和线程锁……而Laszlo中的javascript就很好，直接面向的是这些event。再也没有反射。完全的解耦。
xul形式是最合适的，还有另外一个理由，应用的本身需求就是描述性的。

Domain Design

今天Task系统的领域模型在Robbin的指导下进行了重新地设计，已经是第四次写hbm.xml了。
最近的确工作效率十分的低，状态也不好。不过实在没有想到自己设计的领域模型竟然这么差。
收获有2点:

1. "不要"原则，领域模型能砍得就砍，映射关系只在必要时给出双向的，能用component不用one-to-one
2. 总体的一层层深入的分析问题，而不是在一点上不断展开
   

真得有点不好意思了，想想自己还去指导别人设计hibernate，还好意思说用hibernate已经13个月了。

开头难

新工作已经两个星期了，前两天Robbin来了一趟以后才懂怎么去做，不知道一直在墨迹什么，其实也是我在新公司说话没有份量吧，不管是开发方法还是项目管理方法，都只有等Robbin来了他们才听得进去。
这两天总算忙起来了，开始开发。和人一起开发一个Hibernate+Spring项目，对等的身份，我感觉是第一次。
这种感觉是很开心的。
以前的经历总是仿佛自己在写教程，忙半天别人只有看得份。很不爽。
不过，在阅读别人写的代码的时候总有些不自在，不符合我的编程习惯的我就忍了，有一些错误的编程方法，我今天还是和老纪谈了谈。还好，没生气，呵呵。我记得Robbin再三嘱咐过我，要处好团队合作。
还有，我这几天在设计Hibernate的时候也是总是想Robbin说要设计的容易扩展，当然也是我一年多Hibernate编程的经验了，无数次和别人商量之后写下的持久层映射，总算在今天老板有大改特改需求之后仍不需要改什么。

准备新工作

以前的时候是紧张就拉肚子，现在一紧张就犯困
哈哈
所以今天是一路哈欠去面试的，到了，却也紧张的忘了紧张了。我是浑身战栗的见到了Robbin。简单交谈以后，和论坛上的Robbin有点对不上号：也就照片很像，完全感觉不到严厉。
前几天也没有太准备，问到以前的项目的时候，我还要极力回想一下，终于最后还是轻描淡写的扯到了Laszlo上边。嘿嘿嘿

老板的那关相对好过，因为主要是他说话。
感觉性格居然和我有点相似，说话也是东拉西扯的，想啥说啥。

周一开始上班啦，好期待……

眉目

瞎忙了一个月，Laszlo的项目终于有了眉目
laszlo中的javarpc的使用不像在laszlo forum上那些人说的那么难用，对象机制还是很酷的， 可以以javabean方式返回hibernate的po。
不过用了javarpc这点是方便了，但是laszlo写出来一个通用的分析一个Array的javaObject然后再循环添到一个view里，还是花了我好一段时间的，尤其中间还有图片格式。真是没有xpath来的容易，但是好象要对象的多

偶像来信

出去逛街，真是诸多不顺，想买的东西一个没有买到。
晚上回家，居然收到偶像Robbin的来信，真是受宠若惊。哈哈，而且有可能改变一下现在的生活方式，换一个新环境

过敏了:(

最近真是诸多不顺,女朋友给贴了眼膜,结果第二天早上起来发现过敏了,密密的小水疱.而且还在扩散中.哎，那就老老实实在家呆着吧。
mdc的服务器我想记一笔，免得过后又忘掉了。我想有机会的话，还是给他出个下一版，用上项目管理的一些技术。
我把以前模仿的简单http服务给换掉了，用了xmlrpc里边带的那个WerbServer。应该是标准多了吧。几乎没有怎么改，把"POST"换成了“GET”,然后加了一行处理的入口，不过uri.subString(1)这件事情还是把我折腾了一下午。昨天已经写好了的，可是只是着急测试，结果远程服务器，我的计算机，还有CVS上的版本都不同。我忘了，结果来了一个大同步，哎

一个人

阳光直射着我的眼睛，屏幕里清晰的印着我的像，蓬松的头发，躲避着阳光的眉头。
阳光好像拽住了我的思想的披风（看过超人特工队吗？）， 思维在原地刨着，该死的，我什么也想不了。
项目是着实的简单的，可是我仿佛更乐于在wiki上编辑着需求，分析和设计，在建模以后甚至一个字符的程序也没有多写。我好像花了太多时间在想象这个项目如果有很多人一起写该如何进行，如果有更多的需求以后该怎么办，设定了很多不太可能的危机。
我感觉都已经很久没有在eclipse上边工作了，害怕。
原来脑子也没有那么好使，Laszlo的文档看了6遍了，很多东西还是没有记下来。

我都说，“再给我一个人，我可以让效率大于200%”，可是还是我一个人在做，这真是一个不该帮的忙吗？到底是什么限制了它，人手不够？还是我个人的情绪太重了？是时间吗？

回到北京

北京还是老样子，风那么猛，阳光那么灿烂。
早上起来洗脸，疑惑自己还在大学，那么不情愿的眯着眼睛去刷牙，用冷水洗头……
今天开始要好好工作了呃。

建模

在wiki上连续工作了两天
一个月都没有怎么写代码了，今天感觉特别踏实。
Together真是个好东西，以前没有发现，还一直用Poseidon，要把图片放在wiki上了才发现背景是个海神……
框架设计还用FW做得，好久没有画画了，哈，也感觉特别有趣。
raible的wiki上不知道怎么能把java代码也写出来的，本想写一个plugin，没成，后来想改CSS，也没有弄得特别好。
看源代码知道他是用Forms的pliugin加上java2html做得。但是我咋就不行呢！
明天……
后天……
然后就可以回家啦！
都快天亮了，咋还不困

新项目

一个新项目让我举足无措。
愿望是好的，我想用Laszlo+Spring+Hibernate。
Laszlo只能算是阅读过两次文档，没有IDE，没有完整的功能和语法帮助，我打算再正式开发前，至少再详细阅读10次；
Spring关于ORM的AOP部分还算熟悉，但是又想尽可能多的使用它，也在不停的看他的各种文档；
Hibernate曾经应该是很熟悉的，写了那么多关于他的blog，可是也有快两个月没有折腾他了。
暂时还是想用javarpc来做通信，虽然远没有Flex的RemoteObject那么Cool，但总感觉要比xml-rpc和soap先进一些。也有些人说可以和Struts结合，想起来的确应该写得比较简单，但是扩展、修改起来的确是个麻烦。
javarpc，好吧，那么spring那边怎么写呢，也是写一堆Action吗？有点困惑。

这么多文档压在我脸上，让我忘记了实践，或者说恐惧了实践。我越来越觉得自己不是在编程，没有主义，毫无自信。我这是怎么了？
每天都在想着制定一个计划，在25天的时间内搞定这一切。
~~~
好吧，Laszlo的开发，应该一气呵成，因为实在是需要很多经验。那么我就花时间先把server写出来吧，看看action可不可行，session范围的javarpc可不可以。把所有的文档中提到的功能全部都实现了，测试了，再来表现层。

山口

山口

--黑塞

　　风在勇敢的小道上吹拂。树和灌木留在下面，这里只生长石头和苔藓。没人到这里来寻觅什么东西，没人在这里有产业，农民在这上面也没有干草和木材。但是，远方在召唤，眷念在燃烧，眷念在岩石、泥沼和积雪之上筑成这条宜人的小道，通往另一些山谷，另一些房屋，另一些语言和人群。

　　到了山口的高处，我站住脚。往下的道路通向两侧，水也流向两侧；在这儿高处，紧挨着的、手携手的一切，都找到了各自的道路通往两个世界。我的鞋子轻轻触过的小水潭的小堆残雪，一滴滴雪水落向南方，流向利古利亚海汇入大海，这大海的边缘是非洲。但是，世界上所有的水都回重逢，冰海和尼罗河融合成潮湿的云团。这古老、优美的比喻使我感到这个时刻的神圣。每一条道路都引领我们流浪者回家。

　　我的目光还可以选择，北方和南方还都在视野之内。再走五十步，我眼前展开的就只有南方了。南方从浅蓝的山谷里向上呼出多么神秘的气息啊！我的心多么急切地迎着它跳动啊！对湖泊和花园的预感，葡萄和杏仁的清香，向山上飘来，还有关于眷念和罗马之行的古老而神圣的传说。

　　回忆像远方山谷里的钟声从青春岁月里向我传来：我首次去南方旅行时的兴奋心情，我如何陶醉地吸着蓝色湖畔的花园里浓郁的空气，夜晚时又如何侧耳倾听苍白的雪山那边遥远的家乡的声息！在古代神圣的石柱前的第一次祈祷！第一次像在梦中那样观赏褐色岩石背后泛起白沫的大海景象！

　　陶醉的心情不复存在了，向我全身心的爱展示美丽的远方和我的幸福的那种愿望，也不复存在了。我心中已不再是春天。而是夏天。陌生人向站在高处的我致意，那声音听来另是一种滋味。它在我胸中的回响更无声息。我没有把帽子抛到空中。我没有歌唱。

　　但是我微笑了，不只是用嘴。我用灵魂，用眼睛，用全身的皮肤微笑，我用不同于从前的感官，去迎那向山上送来芳香的田野，它们比从前更细腻，更沉静，更敏锐，更老练，也更含感激之情。今天，这一切比往昔越发为我所有，同我交谈的语言更加丰富，增加了成百倍的细腻程度。我的如醉的眷念不再去描绘那些想象朦胧远方的五彩梦幻，我的眼睛满足于观看实在的事物，因为它已经学会了观看。从那时起世界已变得更加美丽。

　　世界已变得更加美丽。我独自一人，并且不因为孤单而苦恼。我别无其他愿望。我准备让太阳把我煮熟。我渴望成熟。我准备去死，准备再生。

　　世界已变得更加美丽。