1 对于类型是checkboxgroup的数据，数据库中保存数据的格式是value1,value2...valueN，其中1~N的数据有可能不存在，如果选中则存在，最后拼接成一个串。
在Ext中，通过Record对象向FormPanel中的内置对象BasicForm加载数据时，采用的是setValues方法，而setValues第一步要通过Record中定义的name使用findField方法找到表单元素，遗憾的是，继承了Field的checkboxgroup组件并不能正确的通过getName返回自身引用，所以，需要对getName方法进行重写，此外，为了适应我们采用的数据格式，对于该组件的setValue（被setValues调用）和getValue（获取到已加工的数据，此事后话）也要进行重写。故而对于形如：
{
xtype: 'checkboxgroup',
name: 'biztype',
width: 220,
columns: 3,
fieldLabel: '业务类别',
items: [
{boxLabel: '类别1', inputValue: '01'},
{boxLabel: '类别2', inputValue: '02'},
{boxLabel: '类别3', inputValue: '03'},
{boxLabel: '类别4', inputValue: '04'}
]
}
的checkboxgroup定义，需重写类如下：
Ext.override(Ext.form.CheckboxGroup,{
//在inputValue中找到定义的内容后，设置到items里的各个checkbox中
setValue : function(value){
this.items.each(function(f){
if(value.indexOf(f.inputValue) != -1){
f.setValue(true);
}else{
f.setValue(false);
}
});
},
//以value1,value2的形式拼接group内的值
getValue : function(){
var re = "";
this.items.each(function(f){
if(f.getValue() == true){
re += f.inputValue + ",";
}
});
return re.substr(0,re.length - 1);
},
//在Field类中定义的getName方法不符合CheckBoxGroup中默认的定义，因此需要重写该方法使其可以被BasicForm找到
getName : function(){
return this.name;
}
});
2 通过内置对象basicForm的getValues方法可以获取到一个form的完整json数据，但遗憾的事，这里取到的是dom的raw数据，类似emptyText的数据也会被返回，而Field的getValue方法不存在这个问题，所以如果想要返回一个非raw的json集合，可以给formpanel添加如下方法：
getJsonValue:function(){
var param = '{';
this.getForm().items.each(function(f){
var tmp = '"' + f.getName() + '":"' + f.getValue() + '",';
param += tmp;
});
param = param.substr(0,param.length - 1) + '}';
return param;
}
这个方法同样适用于上面定义的checkboxgroup，如此就可以把前后台的数据通过json统一起来了
摘要: 当前的富客户端可以包含两部分：分别为JSP页面和通过富客户端js组件（如extjs）渲染的组件化窗口页。针对这两部分分别做如下处理：
对于JSP页面的部分采用JSTL标准库的fmt标签，如通过：
<fmt:message key="page.login.title"/>这样的形式进行展现，其中message对应的文本在服务端配置，并在web.xml中配置资源文件的位置，也可以采用s...
阅读全文
看此文前请保证jar包中有至少一个Main方法入口，及图形化的界面。
并保证META-INF/MANIFEST文件中的Main-Class已经指向之前实现的main方法入口。
最近硬盘坏了，于是重新安装了OS，发现拷贝后的jdk或jre（未经安装的版本），不能打开jar文件执行（jdk版本1.6_11），
于是在打开方式中指向了javaw程序，发现无效，并提示"cannot find main class", 与此同时windows把jar类型的文件关联到了
指定的javaw程序上，上网找了一通，没有人提及这个问题的解决办法，而显然这个问题又不是由开篇中提到的问题导致的。
于是在注册表中当前用户配置中删除了当前jar类型的定义。但是重新尝试后依然无效。
于是重新安装了jdk，发现这次可以打开jar文件了，并且这次用来打开的程序从打开方式来看仍然是javaw。
比较注册表中文件类型的定义，并没有差别。从文件夹选项 -> 文件类型来看终于看到了差别，
高级里面的open操作定义如下：
"C:\Program Files\Java\jre6\bin\javaw.exe" -jar "%1" %*
而如果我们自己选择javaw，默认的open操作是没有 -jar参数的，必须手工加进去。
我们知道java启动jar包的参数是 -jar，但是记得以前javaw是可以直接打开jar的，不知什么时候起也需要带有-jar参数了。
所以对于一个拷贝的绿色jre只要修改一下open操作的定义就可以解决上面的问题了。
解决了上面的问题，又产生了新的问题，之前选择打开的javaw程序在打开方式中丢不掉了，比较多余，这个可以在注册表中修改
在HKEY_CLASSES_ROOT\Applications下面找到响应的程序删除就可以了，原来每次用一个程序打开一个类型的文件windows都会在
注册表中这个地方留下相关的记录
偶然间注意到一个困扰了我很久的问题，那就是如果我不通过Socket而通过应用层的某种基于文本的协议，比如SOAP进行通信的话，
如何传递二进制的数据呢？现在SOA，Web Service等很火，应该会遇到这种问题吧？
现在已知的方法可以通过Base64进行编码，其原理和方法见：
http://baike.baidu.com/view/469071.htm
这种方法采用了字节中的6位进行文本转换，并且在其他论坛上也看到了帖子说淘宝的搜索也采用了这种编码方式进行处理。
但是采用了5位进行转换。并且大胆地给出了5位转码的算法，见：
http://www.javaeye.com/topic/286240
不过这种5位的转换会产生更多多余的字节，6位的转码充分利用了现今的可读文本，可是5位却没有，因为5和8的最小公倍数是40，
所以当每转换40位即5个字节的二进制数据需要8个字节来表示，这样就多产生3个字节，浪费的效率是3/5, 而6位转码浪费的效率是
1/3。而且随着字节增多，转化效率也在下降。可见采用5位转码是一种既浪费空间，又浪费效率的解决方案。在不增加url长度的情况下充分提高效率，6位编码是最佳的。如果可以任意的饿牺牲url长度，
可以把0-9全部拿出来当做标记位，0-9不会单独出现，这样一共有10*26 + 26 = 286 种可能还不包括小写字母，
此外还有=，+，-什么的至少256可以编码8位的字节了，这样处理效率就提高了。
现在把问题优化一下，人类可读无歧义的文本码有0-9，A-Z,a-z共62个
设取出x个作为标志位则(62-x) * x + (62 - x) >= 256
解这个二元一次方程得到:
3.366<=X<=57.634
考虑到编码的文本长度，取x的最小值，即 4
最优解：
用0, 1, 2, 3做为标志位
4-9，A-Z, a-z参与编码并与标志位配合实现8位字节的文本化
可以看到这种方法的转码效率会比较高，但是空间冗余大。
此外其实可用的文本不知62个，包括感叹号等用上后补足64 = 2^6
它的高位是 00
那么只要再找到三个文本符保存其他三个高位01 10 11就可以了
这样的转码空间可以更小一些。
想法还很不成熟，欢迎大家批评
摘要: 最近在学习JavaScript，发现不论是ext还是prototype都很推崇json这种通信协议的格式，但是这两个框架都是比较偏前端的，和dwr不同，dwr是一个一站式的ajax框架，不仅提供了客户端的工具方法，也包括服务端的配置和通信的处理。
而ext和prototype等仅仅设置好了json的接口并对ajax通信做了封装，相对而言是一种比较“纯粹”的AJAX实现，当...
阅读全文
学过软件工程的都知道，软件产品的生产周期是一个经历若干阶段的漫长过程，包括需求获取 - 设计 - 开发 - 维护等等。
需求阶段 - 总想考虑到所有的问题，或是一切按合同办事。但在现实中根本不得能，因此很多公司开始提倡“随需而变”的能力，希望快速的响应用户的需求变化
维护阶段 - 总希望自己开发出来的东西一劳永逸，永远不要再产生任何麻烦，产生了麻烦也不要找到我。甚至有些项目组的人员开发出来一大堆不成熟的产品、项目后撒手不管，走人了事，毫无职业操守，亦是对自身行业声誉（至少是国内IT服务提供商声誉）的一个打击。真正的项目开发不应该这样，一定是非常易于维护的，能够快速地找出问题的所在，或是新需求切入点的所在，然后解决
很明显，前面提到的两个问题都要也只能通过设计和开发来解决。问题来了，怎样开发出的软件才能快速地响应需求，易于维护？可以有很多不相冲突的说法，比如解耦，比如通过POJO封装数据等等。这些东西流行开来以后，很多人有疑问，为什么我的项目中一定要用这些框架？我不用这些框架也可以快速的开发出我要的功能，而且更加简单，等等。如果孤立地从设计和开发的角度看这些问题，这种说法并没有错误，但是如果从整个软件开发的生命周期来看，则不是这样。当然，这里还有一个是否“过度设计”的trade-off在里面，不过那又是另一个话题了。
再说说各种各样的平台吧，它们和框架不同，软件体系结构中有一种架构模型即层次模型，我们现在的TCP/IP协议栈即属于这种模型，我们的软件对于平台产品的依赖是一种朝向稳定的依赖，就好像我们在调试代码时往往不会去调试操作系统API的bug一样，因此在开发这种平台层次级别的产品时就没有必要再去采用那些为了保障“企业应用”Web软件生命周期中所采用的方法了，完全可以用最基础，最底层的手段。只要能够做到高效、稳定即可。因此，平台中间件产品的开发必须和应用软件产品分开来看，虽然它们可能都在用Java这种编程语言。
本科读书时，曾听过离散数学老师一句很精彩的论断：“只要能够形式化的东西，就可以自动化”。可是今天我不谈离散数学，倒想说说其他不相关的东西。
你一定听到过“一流的企业卖标准，二流的企业卖品牌，三流的企业卖产品”。
什么是形式化？为什么形式化的东西就可以自动化呢？撇开数学符号不谈，对企业来说，形式化的东西可以是一些规章及做事的方法，生产产品的方法等等。为什么人民币稍一升值，中国的中小制造型企业就要痛苦不堪？因为我们每既没有品牌，更没有标准，拿生产DVD机为例，最初的90年代生产DVD机卖到欧美很赚，可是现在据说不赔钱就不错了，因为要缴纳一大笔的专利费。中国的大多数企业处在整个产业链的最下端，所得的利润的大多数被其他企业剥夺了，因为我们用的是别人的品牌，别人的标准。我们的公司在全球经济中处于“民工”的境地。
回到我们的问题中来，一流企业所做的标准，是生产一种产品的方式和规约，这一层面是抽象世界的最高层次，无法对这层抽象的产生进行形式化，所以是一种创造性的劳动；二流企业所卖的品牌是对一种产品具体生产方法的规约，通过“模板方法模式”的应用，这一层次的抽象的模板可以从上一个层次的形式化中自动化，然后只需形式化具体的操作细节，对于生产细节的形式化，也需要一定的创造性的劳动；三流的企业是一部机器，因为到此为止一切的东西都已经形式化了，只需要有时间和精力的机器去自动完成而已。
让我们好好想想在一个知识经济的社会里，什么事物是创造性的，是只能被形式化而不能被自动化的。因为只有人类的创造性思想不能被机器所取代，这也是为什么机器人无法取代人类的原因。
80年代出生的人应该记得历史教科书中的论述，工业革命时，一些工人去砸毁机器，觉得这些机器剥夺了他们的工作。如果有一天，老板突然来告诉您：你可以离开了，请不要沮丧和懊悔，因为您早该意识到您其实就是一部机器。当然为了防止上面悲剧的发生，早点去从事有创造性的工作吧，停止对于各种软件自动化辅助工具的抱怨和担忧，勇敢地迎接明天。
还记得小时候常看的电影《神鞭》吧！
偶然间看到下面有一个网友慨叹普元的强大，而开发人员的渺小。
小弟刚刚参加工作，也在项目中接触到了普元的EOS。普元的这个东西怎么说呢，就是乱用XML然后Spring没做好就变成那个样子的，同时失去了类型的表述，一部机器要进行装配需要组件和零件，软件应该自上而下，分而治之，这是上个世纪70年代，学者们就达成的共识，所以关于“银弹”神话的唯一结论就是——“没有银弹”。
为什么说EOS是没有做好的Spring？
Spring简化了对象的装配，强调重用，是建立在面向对象基础上的，是建立在敏捷测试基础上的，是建立在强类型基础上的；
而EOS则是建立在面向过程的基础上的，建立在不可测试的基础上的，建立在毫无类型基础上的（全是String）
然而EOS也有很多的优点（据小弟不完全发现）：
1）EOS固化的开发流程强制一个team从一种易于维护的结构组织Web，包括页面，表示层，逻辑层等等。否则的话就需要一个架构师来做出规约，但仍不易于管理；
2）EOS的画图功能让人耳目一新，从“代码即文档”的哲学出发，这些画图很好地诠释了代码表述的内容和结构，给程序的维护带来便利。
3）相对于OO和J2EE传统开发，EOS易于上手，学习曲线较短。但是这一点有争议，EOS的知识不具备通用性。
综上，根据2-8的关系法则，在某些领域EOS的确有其优点，但是认为EOS完全“解放”了程序员，则是不负责任的说法。
这只是我的个人看法，欢迎大家就此话题讨论。
联合国是国家间的标准化组织，可惜一超多强们只把它当作是一个道具，需要时拿来用一下，不需要时完全可以踢到一边。
历史上，每个朝代都认识到失败的教训，却最终都迎来了相似的结局。
有人说，软件行业是一个天生的垄断行业，其特质是，产品研发的过程异常的复杂，但产品一旦出炉，就可以疯狂而不计成本地生产。只有NRE Cost，眼下的软件行业也出现了群雄逐鹿的场面，上游产业被几家大公司所瓜分，这些大公司如果能互相牵制，则会坐在一起，成立一个组织。如果一家独大，则我行我素，称王称霸。
看看他们的一路成长：
初始：
他们想占有你，最初都会很乖。就像女孩在成为家庭主妇之前总能收到男孩的礼物。
成长：
大公司们也渐渐从规范的参与者，变成规范+的树立者，比如IE，Office，再比如Oracle的特性等等。
称霸：
市场占有的差不多了，可以不顾客户的意志做自己喜欢的事情，反正你已经离不开我。
消亡：
客户们怨声载道，新的“符合规范”或简洁明了的产品出现市场。
希望这些大软件厂商们能够吸取教训，也希望小软件厂商们将来不要走入历史的怪圈。