技术点滴

来源: BlogBus 原始链接: http://www.blogbus.com:80/blogbus/blog/index.php?blogid=6781&pg=9&cat= 存档链接: https://web.archive.org/web/20050123045859id_/http://www.blogbus.com:80/blogbus/blog/index.php?blogid=6781&pg=9&cat=

技术点滴 几年的软件研发做下来，接触的技术，零零碎碎加起来，居然手指不够数了。不少东西，是帮工程部门解决完就扔一旁。弃之可惜，何不借这网络一角，留下一点记忆？遂有此Blog。 首页 一路走来 (43) 翻译文章 (4) Spring Framework (6) Rich Internet Applications (16) 对软件开发的思考 (6) blog on blog (7) GMail碎碎念 (5) Java Basic (4) : 第一页 [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] 最后页 2004-06-15 10:32 中文blog比较之二：bus与driver的使用体验 首先说明一下：这一系列比较更多是私人观感上的，并没打算写成什么“系统全面”的东西。所以，东一鳞、西一爪，身为“用户”的我对什么来了兴趣，就会去看看那一部份。 因为私人兴趣泛滥的原因――我不习惯把所有的自己在一个地方表露出来――上周在blogdriver开了一个新blog，几天用下来，感觉多少有点不一样。 懒得把每一项内容都列出来一一比较，只说说一些很直接的体验。 1、总的来说，driver的风格比较现代，给人以比较新的web印象；bus则非常传统。 2、driver把目录栏做成了紧贴浏览器的工具栏的样子，本身是不错的构思。但我刚开始使用的体验非常糟糕：那一栏直接被我忽视掉，或者说，由于其所处的位置导致无法进入我的使用视野，成为我的视觉盲点，以致我傻傻的不知道该怎么开始管理。相对而言，bus的目录树是最常见的方式，使用起来更简单一些。 3、日志撰写方面，两者都是用了js写编辑器，所以在缺点和优点方面都是比较明显的。bus值得称道的地方在于比较多的编辑选项，尤其是插入网页、上传文件、预览这些功能都很实用，driver的这个编辑器也足够使用，但能够多一些功能自然是更好。不过driver的编辑页面也有胜出的地方，它可以设置日志是否展开、置顶，设置浏览对象的控制，尤其后者，从中可以看出系统设计者的体贴。而且有保存为草稿的功能，也相当人性化。不过，不知为何，driver特别喜欢把各项内容收缩起来，以致不留意就不会发掘出这些功能来。另外，虽然没有仔细比较，但感觉driver的代码转换比较优化一些。 4、日志管理方面，driver按分类显示列表，bus则把所有日志放在一起。当日记比较多之后，前者可能会更方便一些。我个人的希望是两者都能够提供，缺省为全部列出，同时可以按分类进行过滤。 5、日志编辑方面，driver把功能分得很细，刚开始使用并不舒服――因为这意味着你要为了改某个小地方去找个不停。我想这是开发者从系统优化出发的考虑。bus则把全部东西都一次载入，挺好，但如果用户再多之后，这一项，也是不小的系统负担。 6、文件管理方面，driver据说提供2M空间，但我到现在也没找出那一项在那里。bus方面不用说，可以去买。 7、模板方面，不管从数量还是质量上看，bus都不是driver的对手，我一开始真是看得流口水。bus在这方面实在太弱，事实上，可以说在界面方面，driver已经是相当专业的水准，不管是模板、还是界面元素的设计，driver都显得专业，我估计他们拥有相当优秀的界面设计师。bus更像是业余人士的笨拙设计，大概主体是由程序员搭建的，美工只起点缀作用而已。不过，这方面bus也有亮点，就是他们可以修改设置，支持在模板上增加一些内容，对于有一定HTML编写能力的朋友，那是相当不错的。而driver的模板则是写死的，没有用户发挥的余地。 8、备份管理方面，要特别表演bus，可以随时建立存档、备份文件，真是人性化得很。driver似乎只能每月统一建一次备份，更没有存档的概念，让人不爽之极。从程序员的角度，我能明白这又是节省资源的考虑。不过，嗯，driver根本就是那种扒皮资本家-- 9、有些功能是你无我有的，比如driver有留言功能就挺不错，实用。又如bus有作者回复的功能，本意很好，不过我觉得应该把回复在评论栏显示出来，不然谁知道你回复了啊？ 10、发布之后，毫无疑问，driver的页面是漂亮得多，而且支持展开收缩之类的功能，但同样存在使用复杂的问题――别以为点一个键或点一个链接是很容易的事，那同样需要“寻找”，而不够醒目的提示对于用户永远是一种折磨。bus的页面中规中矩，没什么好说的。不过，这里要提一下，bus的程序员太懒了，回复框那么小，明显是用了缺省的textarea，也太折腾用户了吧！建议把回复框挪到底部，放大一点，增加一些基本编辑选项。唉，这么简单的事，等这么久都没人做。 11、bus非常优秀的地方是支持即时刷新，而driver为了减轻系统负担，需要等待做静态页面转换。转换无所谓，对于提高速度也有帮助，可是，为什么得“等一会”？搞得发布之后没办法立刻看到结果，程序员失职！ 嗯，这种无中心内容的比较，再写出10点来好像都很容易呢。不过，又没稿费，还是打住，等我下次来兴致了再说吧。^^ 总的来说，driver精致美观，细节各方面考虑得很多，“精明过人”，如果能够持续发展下去，相信会很可观。bus朴素保守，显得更为粗旷一些，但给了用户更大的发挥空间，冲这一点，我也会继续以bus为主。――这或许也可看作我的择人原则：我欣赏精明的工作伙伴，但更愿意亲近粗放的朋友。 linrun @ 10:32 | 阅读全文 | 评论(3) | 引用Trackback(0) | 编辑 2004-06-14 22:54 世界上有些事情是很巧的 刚刚在跟一个记忆力不好的朋友聊天时，说了这么一段话： 世界上有些事情是很巧的 你可以想象一下，所有的新blog，总共只显示10条，有新的马上刷下去 总共18858个blog 然后你随手打开，看到其中一篇blog正好是写给你的... 这种事情，是不是很好玩？ 对，没错，我刚刚遇上这种事情。前两天为tapestry和spring整合的问题跑去 寸心知 问了一下，他今天才看到，很热心的做了个回复，而我，正好在blogbus.com的首页看到了这个回复。 有趣的事，应该记下来与人分享。 Ps遗憾的是，对方站长不是mm...哈哈 linrun @ 22:54 | 阅读全文 | 评论(0) | 引用Trackback(0) | 编辑 2004-06-13 17:23 补充一下“Tapestry整合Spring” 不知道有没有人留意到，上一次我的说法是：“ 将Tapestry整合到Spring里去 ”，而这一次，我则是说：“ Tapestry整合Spring ”。也就是说，主语和谓语倒置了。这代表我看法的改变。一开始我是以Spring为主体，想用其构筑应用框架，然后在表示层、持久层加插其它需要的技术，比如Hibernate、Tapestry。 然而，实践中，我感觉到，应该把Spring放到更低的层次去考虑，不是将其作为主体，而是将其作为“粘结剂”，作为“辅助工具”来使用。这么说吧，我在view层选择了Tapestry的解决方案，同时希望能够应用DI模式，那么我就把Spring的这块功能拿过来使用。同时后端的设计人员又选择了Hibernate做持久层的解决方案，那么Spring的DAO那些东西很可能就帮上忙，于是引进来。 这个思路的变化对于总体方案可能没有什么影响，但对于我在逻辑方面说服自己却很有帮助。至于会不会有一天我又倒过来思考，那就看实践会带给我一些什么样的体会了。 linrun @ 17:23 | 阅读全文 | 评论(0) | 引用Trackback(0) | 编辑 2004-06-13 00:40 Tapestry整合Spring实践 两个月前，写了一篇blog，名为《将Tapestry整合到Spring里去》，是根据文档做了理论上的说明。这阵子终于开始动手做，由于犯了一个很低级的错误，浪费了很多时间，直到周六才“摆平”，很高兴。网上这方面的资料非常少，我把实际操作过程再介绍一下，也算补一下文档的不足。事实上Spring网站的文档是给对Spring和Tapestry都有开发经验的人写的，多少有点过于简略，不是很方便使用。 第一步：写一个Java Bean供后边调用： package my;//接口 public interface IBean { public void amethod(); } package my;//实现类 public class Bean implements IBean { public void amethod() { //do something; } } 第二步：编写Spring的context config文档applicationContext.xml，放在web应用的/WEB-INF目录下