CMS漂流

kolidon中项目实施过程中发现，Drupal项目应用中有如下问题值得关注：

在中等规模项目中，对核心代码及各开源模块源代码的尊重及版本控制与跟踪。

在华的外企和外包企业，对Drupal开发认识不足，因此常常招聘新手来进行“组装”，这些新手无PHP编程基础（可能拥有其他程序开发经验），无充分项目经验，这可能带来的问题是实施计划与项目进度不可控，代码质量与可靠性不可控，维护计划混乱。

实际上，更大的问题在于，即使稍有经验的Drupal开发人员，亦可能无法形成自己的开发规范/契约。自行开发的模块命名、功能分工、模板等均无法控制。

解决方向：

1. 减少对无PHP编程经验的开发人员的招募。应注意开发过程中的标准化文档的生成（即，所有解决方案均应经过讨论和一致许可并形成可供回顾的标准文档）。

2. 每周一次的集中学习，实施质量评估（点评）必不可少，在此过程中，重点讲述不周密的实施方案可能给后期开发，需求变更及维护带来的影响。

3. 在对人员的培训过程中，尤应注意对Drupal核心源码的集中学习，和对Drupal文化的讨论。

4. 若有可能，组织团队成员协同开发和维护某个开源模块。

kolidon识于2009年8月

在转场了新光天地的地下一层，两间上岛咖啡店，最后跑到24小时的永和大王用我可怜的移动3G上网卡撑了八小时，喝掉上百块人民币的咖啡和豆浆后，我终于成功地将桥接器的测试站点放到了网上。并且，重新整理了所有已经发布的代码，进行了尚算精细的测试。

请点击链接看这篇不断更新中的文章：
http://blog.treeber.com/20090104/500.html

目前我止，QQ上向我问询这个桥接器开发情况的朋友已经很多，但愿这篇文章能让一些不怕麻烦的朋友先跑起来，我仍然在完善它，以便能解决掉目前所有的不完美。

因Ucenter本身似乎不那么完美，很多地方得追进源码才能发现文档的错误，或者，它蛮横地不向其他应用提供新用户注册成功的消息，一个细节是：用户若在DZ一类ucenter应用中注册了，则在Joomla中注册时只能先探测username和email是否在ucenter中存在再给出提示，而不是注册时自动进入joomla系统——虽然已经做到了joomla中成注册完自动进入Ucenter。

估计再用一个小时左右就可以直接将其改成在任何用户在joomla注册时，直接将Ucenter中存在但joomla中不存在的用户同步过来，这样就不用看到丑陋的冲突提示了（见内文中的详细说明），或者，Jianer同学提到的jfusion也可以进入我们的视线——虽然，对jfusion我比较持怀疑态度。

若有开发者愿意合作，我们应该弄几个饭局讨论下如何将其做成组件，如何不用修改核心代码（目前已经有思路了但还得试）。

有点迟，主要是这半年工作有点千头万绪，另外，最近在新单位主要用Drupal。
祝大家顺利。

Last Thursday I went to Guangzhou,  From Beijing, by China Eastern, MU 2124, MU 2301(connecting flight in Xi'An).

It's pretty firm when you leave from your daily affairs then have a travel.

Had have a talk with Tim Lee in Guangzhou about his company and in Shenzhen, a friend working in HuaWei NGN core product line taught me many knowledges about soft development management and share a development tool named Source Insight(a C language editor).

I'm learning C for the second time in order to do much more in web server software and Mysql DB.

There were two interviews for me in Monday and Tuesday, I booked an early flight in Monday but the CA1306 was delayed, thank godness it's just 1 hour and when arrived at Beijing, it was raining. 

In Shenzhen Airport, 13th July 2009

最近和朋友合作做了dedecms的一项目，颇有感触。
国内有想法的家伙其实是蛮多的。

一套好的CMS，特别是一套要在国内流行的CMS，几个因素非常重要：

1. 规则简单的，可扩展的模板系统，既支持模板单独定义，亦支持模板通用化（首页、频道首页、栏目清单页、文章页、专题页五个即够）
2. 静态页面生成、未生成静态页面时的预览功能
3. 动态建立内容模型(model)，如产品、软件、视频、图片等需要的信息有所不同
4. 其他如多级分类、对文章的不同标记（推荐、加粗、头条、图片、跳转等）
5. 配套的其他功能如广告、会员、图片水印、附件管理、数据库管理等。

我们分两次，每次半天，挂完了一个四屏长的页面加六七个三屏长的频道页，加栏目清单页和文章页。这在以前是无法想像的（JEECMS除外）。

另外，我们还对专题功能加装了一个插件，实以现对专题的各个节点分别列出文章清单。只需要taglib文件夹中放置一个myspecnote.lib.php的文件即可实现myspecnote的新标签。

{dede:myspecnote notei=somenote  }-----[field:arcurl/]------{/dedea:myspecnote}

在JAVA中这从来不是什么大问题，特别是主流ORM组件如Hibernate的使用，加Struts的validator，不太严格的服务器端验证就差不多O了。

在PHP中，我们一样也面临这个问题，ORM当然也不再是问题，目前有些CMS中也已可见轻量级的model自动生成（根据数据表），生成无外键的单表对象模型，另一些知名的开源ORM当然已经和Hibernate一样实现了复杂的ORM。

我们这儿先说数据格式验证。

kolidon倒是见过其他公司自有的商业框架中的复杂的验证模型，他们试图以java开发者的视角观察一切，巧合的是，这帮家伙几年前就在 joomla1.0上实现了自已的1.5…:-)。不管怎样，这样的框架已基本堪用了，甚至，有时能感觉到，只要这帮家伙再努把力，甚至能自动生成前端js验证代码。

但实际使用时，仍然面临太多问题，如代码复杂度倍数级增长，代码量狂增导致的性能损失。若一个代码框架语法和逻辑过于复杂，这些后果似乎是必然的。

难于分解的复杂系统最终将被抛弃，因为维护成本、学习成本还有，随着应用的市场系统，构建相对简单的系统是如此方便，而将相对简单的系统组合后，仍然会有无限的可能。

一个事实“我们接触的绝大多数项目，都是需求变化极大的网站平台，离“WEB应用”这个词其实仍然有那么些距离。也就是说，无论在价值及使用方式上，对数据验证一致性的要求非常低。另外，虽然我们一直在努力，但事情似乎永远没完没了。

典型的例子是wordpress个人博客的反垃圾评论的战争。见这儿、这儿、还有这儿。

道高一尺、魔高一丈。如果无法可想，那就换一种思路。

考虑一下，只要安全性能过关，那么一个电话号码位数多或者少个一两位，恐怕并没有太严重的后果，因为，我们不可能知道用户填了个虚构的电话号码或者邮件地址——能连到银行去验证信用卡真伪的除外，那个当然也不保险，最万无一失的的是扣掉你一块钱，然后再打给你——这就是我们在当今体验到的极端验证法。

若一个varchar字段超长，mysql数据更可能是自动截断，而整型数据超出范围，能遇上的用户也基本上不可能是合法用户——这种可能性我们在这么多网站项目中基本上就没怎么遇上过。能手工制作URL传入自定义值的非法用户，若还能识别传统的验证码，最终实现了批量向站点中写入数据，只要数据是需要验证才能显示的，那么这些动作能产生的价值就几乎为零（kolidon博客后台中的数万条垃圾评论为证）。

不要害怕垃圾评论，只需要让垃圾永远没有机会露头污染到大家。不完美并不是什么难堪的事情。

我们将注意力更多转到了前台。几年前，我们试用了一些集成式解决方案，更多的是自己写JS。而jquery大行其道后，我们使用Tootip和Validation，事情正变得越来越简单。

同时，我们也在寻找PHP的ORM组件，当前google给出的结论是Doctrine and Propel，满心期待这些组件除了提供基本的OR映射外，还能有后端验证功能，若还能在前端验证上做一些工作就更完美了。

不过，若能有后端验证，从此出发，生成供Validation插件使用的js代码仅一步之遥。