写在Buffalo1.2发布之后
Posted on December 27, 2005
Filed Under essay, life | 10 Comments
buffalo1.2发布了，有了许多感想，有必要写下来。开发过程中的一些点滴，也许并不像像外人一样那样容易。现在开始明白，一些独立以个人之力进行专业化软件开发之路的开发者，是多么的不容易。可以说，每一个新版本release的背后，都留下了辛勤的汗水。
从一开始，就没想到buffalo能走到现在。buffalo 1.0出现后，也许会像jsvalidation一样，轰动的来，悄悄的去，莫名无声。然而，清风和nemo大胆的在Sina的内部系统中应用了buffalo, 证明了buffalo的可用性，这给了我极大的鼓励（事实上，我一直在这样各方面的鼓励中，不断的改进buffalo）。后来社区的引入，逐渐有了像董董，宋来这样的热心的用户，不断提出意见和建议，督促着buffalo往前走；曹晓钢老师也不断提供资源的支持，amowa和buffalo站点都是在他的服务器上。没有各方面资源的支持，我想buffalo不可能走到今天。
buffalo api的实现都很简单，但是都是长期思考后得到的，我认为能够让使用者得到最大自由度的，并且不依赖buffalo的接口定义。当一个新的特性需要被加入的时候，我首先考虑的是是否会加重使用者的学习负担，其次是如何设计最直观最人性，最后才是实现。现在的开发者需要学的东西太多太多了，如果这套api不能在5分钟内告诉他们怎么用，30分钟内不能开始使用，这不能说明这个产品的成功，而正好证明了他的失败。在现在的JavaEE领域，没有把任何事情比把事情弄得复杂更加容易的事情了。复杂不是优点，是缺点。我很高兴的发现，今天发布之后，有新的使用者能够在看完api后说，功能差不多，比DWR简单。
不得不说，开发buffalo的过程是一段痛苦的过程，甚至真切的影响到了我的工作和生活。上班中，我时不时去论坛看看；下班路上，我在考虑如何添加新的特性，如何设计service接口更加兼容IoC容器和自定义的服务。周末，如果没有其他的事情，一般也是在做buffalo. 然而，工作中我也并非自由人，也要管人和被人管。遗憾的是，在这种平衡关系中，我做得并不好。
更重要的是，这种真正意义上的开源开发（至今为止，我没有从buffalo或者amowa或者jsvalidation中得到一分钱）让我的价值观也发生了一些变化。我开始理解Richard Stallman当初开发gcc的那种狂热，也能够理解菲利普·卡兹为何潦倒而终，归根结底，我开始似乎领略到那深邃的开源精神，那种以全世界使用者开心而开心，以使用者快乐而快乐的精神。这种精神能够让人逐渐忽略物质的需求而享受真正的精神世界。然而，我中毒尚浅，深深的明白，全盘接受这种价值观在国内跟自杀没什么差别。
下一步工作，我知道还有许多没有做。目前已经提出的有：表单到DTO对象的绑定，与jsvalidation的集成，对service调用的ACL控制，改进的对有状态service的支持，等等。只要开发者有需要，buffalo会一直走下去。buffalo会放到java.net或者其他的开放cvs上，以接纳更多的开发者。
ps. 我答应了博文视点，从明年开始与夏昕一起写一本关于JavaEE开发的书，工作更多了。
Comments
10 Responses to “写在Buffalo1.2发布之后”
Leave a Reply
永远支持你！
加油，老大！
Michael的buffalo
我现在正在参与的电信的系统，也在一些地方使用了AJAX，用的当然就是buffalo，具体效果就等用户就评价吧。
不过我觉得你在BuffaloServiceServlet中的一个错误一直没有改正，就是不能把_service,_skeleton设为类的私有变量.
1.2中BuffaloServiceServlet已经被deprecated. 请使用新的net.buffalo.web.servlet.ApplicationServlet.
ApplicationServlet的实现方式比我原来想像的方式的更漂亮，只要实现接口ServiceRepository就可以用自己的方式来获取service了，只是我实现了这个接口后，要怎么使用我自己的类？你似乎还没有完成。
private void initServiceRepository() {
if (getServletContext().getAttribute(ServiceRepository.WEB_CONTEXT_KEY) == null) {
LOG.info(“initialize the service repository”);
ServiceRepository repository = new DefaultServiceRepository(getServletContext());
getServletContext().setAttribute(ServiceRepository.WEB_CONTEXT_KEY, repository);
} else {
????
}
}
我们也简单写了个jsvalidation,不过不是定义在config.xml文件里的,而是直接在里面加了个contrains属性,不知到Michale觉得这个思路怎样.
我觉得直接在input里就能看到限制比跳到config.xml好些,也少些配置文件.
不知道楼上说的是不是这种方式
这种方式我以前也用过，但同事都不喜欢，如果有两个相同的表单都需要表单，比如增加和编辑的表单，那不是每个表单都需要写required=”true” maxLength=”4″。现在我们项目用的客户端表验证就是在Michale的JsValidation上改的，但是有些客户端的浏览器在load xml配置文件时总是会出错，头痛啊。
唉，特殊标签被过滤了。
> input type=”text” required=”true” maxLength=”4″<
jsvalidation正在考虑。一直都想那么做的，只是忙于buffalo, 没有时间来整理。以后校验的规则数据支持xml和内嵌属性两种。内嵌属性
input rules=”required;minLength:10;maxLength:100″
类似于css的语法。