月度归档:2009年12月

django的论坛app

在django的资源页面里有个第三方论坛app的比较页面Django Forum Apps Comparison。一眼望过去,可用的app还不真不少,数下了有15个之多。但真正看下来,似乎很难找到一个让人满意的。
我对论坛app的要求是:

  1. 得要自带一个还比较漂亮的界面模板。
    模板的开发工作在django应用的开发中占了很大的比重,甚至可能比写python代码花的时间还多。可惜的是很多的app应用甚至连个最基础的demo模板都没带。
  2. 最好支持Richeditor和BBCode。
    支持BBCode的app还是有几个的。Richeditor的支持基本上属于模板的范畴,参考条目1,似乎还没看到支持Richeditor的论坛(注:我没每个app都看,不能确定,pybb默认模板带了个Markup的编辑器)。
  3. 支持附件。
    国内的论坛应用大多偏娱乐,用户喜欢在自己的帖子里插入图片等东西。虽然可以再单独提供一个上传附件的组件,让用户上传后再在论坛里引用,但用户体验就要差不少了。

既然找不到满意的app,那就只能自己动手做了。目前计划在pybb(注:pybb的许可协议没看太懂,似乎是类似BSD的)的基础上进行开发。目前的开发计划如下:

  1. 先给项目换个新名字LBForum
  2. 换个漂亮些的模板(同时增加richeditor)
    考虑过不少模板。

    • phpbb3 目前最流行的开源论坛程序,css和html写得很不错。但似乎有些复杂了,套用起来有些麻烦。
    • phpbb2/javaeye/jforum 这几论坛程序都长得差不多,UI应当都是参照phpbb2(javaeye的老大自己说了javaeye的界面就是仿phpbb3)来做的。其实也不能说这几个论坛的模板有什么不好。更多的是不喜欢里面过多的table。
    • discuz5 不是太喜欢discuz7的界面。discuz5(springside常用的那款界面)的界面感觉清爽些,但改了些后发现里面的html和css写的实在不怎么样。
    • fluxbb 目前打算用她的模板了。界面给人的感觉不错,html和css写得挺好。界面够简单,要套用模板应当不会太困难。
  3. 增强附件功能
    虽然pybb提供了附件的支持,但功能还是比较弱。
  4. 增加一个公共的个人信息模块
    pybb已提供了一个保存用户个人信息的功能,但通常这些信息会是整个工程所共享的。我觉得这些信息还是单独放到一个专有的app里比较好。这个app可以以代码的方式包括的工程里,需要增加个人信息的时候直接修改model代码。

后记

最后还是选择了完全从头进行开发。pybb里面可以用的东西不多,而且他的开发思路和我还是有些分歧。

JdbcTemplate之BeanPropertyRowMapper

Spring的JdbcTemplate无疑极大的简化了JDBC操作。只是查询出的数据都直接放在MAP里。想要直接从数据库里直接查询出对象的朋友不免要有些失望。

这写天本想给JdbcTemplate做个扩展,让JdbcTemplate自动绑定对象。等写得差不多的时候,很不幸的发现自己只是重复造轮子而已。Spring已经自带了比较完善的解决方案,通过BeanPropertyRowMapper自动绑定数据库的列到对象。BeanPropertyRowMapper的绑定规则是,FiledName相同的绑定,如果绑定失败,将尝试将hiVik转换成hi_vik查找数据库的列。

如果需要查询出一个包含YouVO对象的List只需要做如下操作就可以了。

List objList = DbHelper.getJdbcTemplate().query(sql, new Object[]{}, new BeanPropertyRowMapper(YouVO.class));

java的类ROR框架Play!

Play!一个类ROR的java框架。和Grails不同的是,Play!没有用Groovy等脚本技术进行扩展。直接使用java技术,这对java程序员来说要亲切很多,而且推广阻力也相应的会小不少。

最近简单的了解Play!,感觉确实是挺有意思的一个东西。Play!作为ROR“仿制品”,在开发思想方面和ROR还是比较接近。Play!本身提供了不少开发相关的辅助命令。使用命令创建出的新工程直接就可以运行了。相比之下,基于ssh的开发,光是脚手架的搭建就得费不少事。

数据模型方面使用JPA定义数据对象,直接从对象生成数据库。这点和django比较像,这也是比较符合我开发习惯的一个做法。

模板方面和Django类似,支持模板的继承。Django模板的继承给我的体验很好。jsp页面虽然可以使用include实现复用,但对于结构相似的页面依旧需要重复的include。Sitemesh虽然可以实现类似django模板的功能但看到那繁琐的配置我就撤了。

总的来说Play!给我的印象还是挺不错的,希望在日后的工作中可以用到。

其他

Play!的FAQ里有一个解答让我挺印象深刻的。其中有关于为什么使用不符合java规范的play做包名的说明。play!本身就是一个平台,运行在play!上的东西都将是符合play!规范的,所以不必为play这个包名而计较。play!专注于web的敏捷开发,为了适应web敏捷的需要一些无伤大雅的“另类”做法也是未尝不可的。想自己在某些情况下对代码还是有些所谓的“洁癖”。在django开发的时候喜欢在自己的app外面还要另外加一层包,而这种做法在一定程度上是不符合django做法的(django的app名必须唯一,即使上层的包名不同也没用)。