CMS漂流

在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代码仅一步之遥。

重新发布了当时的草稿并作了修订。

若有问题，请评论或QQ我。

http://blog.treeber.com/20080722/352.html

什么样的家伙可称大牛？
大牛吃什么？大牛干什么？大牛玩什么？
怎么成大牛？
先澄清一个问题：大牛是人，大牛是更加人性化的人。
人生就是解决问题，大牛也一样。
因此，只有两个问题有意义：
什么样的家伙可称大牛？
大牛能发现或提出好问题
大牛能解决相对重要一点的问题
大牛能比较系统地解决某一领域的问题
大牛对这个事情有一套完整的理论，当然实际操作上也可以厉害，更多是假他人之手
大牛永远知道自己的领域——虽然，用一点点时间，他们也可以迅速在相关领域变成准大牛
大牛往往从小牛成长而来，他们不会拒绝解决小问题，但不会沉迷于自己断定不会变大的小问题，这里面，往往有运气
大牛不闭门造车，拼经验更拼眼光
大牛经常有拿不准的时候，非常清楚自己的盲区。

怎样成为大牛？
kolidon/logmin的理解是：
在某一领域持之以恒
基础一定得牢，熟悉基本工具
学会发现问题并清晰表达
培养科学精神，一定的人生阅历，稍广博的视野，多研究哲学和历史，兼修艺术和宗教
一定的洞见能力，能从系统层次分析和解决问题
有个好的平台会让大牛之路顺畅一些，当然大牛常常会有好的平台
最后，不要把自己逼得太狠，注意自己的收入水平和家人的喜乐。

另外，每天看大牛的文章，不能帮自己打基础，解决细节问题。
主要是，培养眼光，发现方向，有时能赚点经验值。
然后，时时鞭策。

by kolidon@2007.10/logmin

虽然总和一般规模的站点打交道，但需求总是千变万化的，当前某个客户的数据库已经达到数千万条记录（10M条规模），虽然离大规模数据处理（G条记录）还差了老远，但已经可以勉强在实际项目中看到点这样的感觉了。

前台访问量没有上来，因此当前的索引状况应付前端访问并无问题，所谓分表、分库现在也完全没用上。

主要的问题在于数据插入，客户需要每次提交一个csv文本，约一万至数万条记录，而.NET组的同事在处理这些记录时，采用的方案是按某字段验证是否存在，若不存在则插入。此字段当然已经有了索引。

但最后的结果是过万条记录至少需要一刻钟时间来处理这些数据，客户认为这个时长不可接受。

因为以前有处理过数百万条记录的经验，因此被抓去给方案。

三种方案：

1. 用户提交数据后，数据进入任务队列，即用户不用盯着浏览器观查页面刷新什么的，关闭浏览器亦可行，这是最基本的。

2.提交的数据先行去重，然后一并放到库里查重，然后使用单一事务一次性插入。

3.若库里面仅以单一字段验证是否重复的话，直接在库里面将此字段设为唯一索引，然后insert插入，返回错误值的则为重复，不重复的则能正常插入。

最后结果，同时采用2和3，在远低于服务器配置的普通PC测试环境下，一万条数据插入可以在1XX秒搞定。

若J1.6真如官方所言的达成其中大部分目标，同时在性能上有所提升，则用户和开发者或会重拾对其的信心。

或者说，从1.6开始，核心功能即开始有向理想中的快速建站CMS靠近的趋势。

见：Feature patches for 1.6

• Implement a new JForm library package [complete].
• Implement a simple way of providing translation in JavaScript [complete].
• Implement new controller dispatchers for more robust request routing [complete].
• Implement a new access control system that needs to at least emulate what is in 1.5, allow adding of new groups and access levels, and allow you to set new "view" rules for at least articles [nearly complete].
• Implement and standardise several new event triggers [in progress].
• Implement a JContent class that will be used by content plug-ins and views [in progress].
• Upgrade to Mootools 1.2 [in progress].
• Finish the new extension updater work [in progress].
• Menu manager re-work -- added since it's broken in 1.6 [in progress].

另外，1.6最终版本预期包括

• Implement unlimited depth categories (but not multi-mapping).
• Refactor the user management system and make it more extensible (eg, allow custom user fields).
• Implement a comments system (including pings and track-backs).
• Implement queued redirects (allows you to, for example, return to the previous page you were on after you edit something).
• Refactor parameters and make them more extensible (for example, plugins could allow you to add additional custom parameters to articles).
• Finish MVC-ing the Administrator components (we need lots of help here).
• Implement CAPTCHA helpers for any form.
• Implement systems whereby external authentication systems, such as LDAP, can map to our new Joomla user groups.
• Re-implement the ability to select multiple categories for some views in com_content (was in 1.0, got dropped in 1.5).
• Implement a database driven installation log.
• Refactor JError.
• Examine the PDF generation system in detail and see if we can make it work properly (otherwise we will look at dropping it if we can't make it work well).
• Localise the Invalid Token messages.
• Drop the Polls component because the quality of that extension is pretty bad and there are much better third-part alternatives available.
• Convert all layouts to semantic, XHTML Strict.
• Convert of ini-based "params" fields to use JSON instead of INI format (huge technical and performance improvements).  Note, the language files will remain in INI format.

当然，kolidon和同事们的理解是，对开发者来说，它的编程约定其实来得比drupal要少，虽然架构仍然过于笨重了一些。

我们试着将1.0更改成一套框架，使某些界面有较多需要的组件变为准MVC架构——比如内容组件，现在components中仅有常用方法而没有前端呈现部分，将前端部分交由smarty控制的模板，而模板按频道-栏目-栏目可单独分派。这个实验现在看来取得了初步成功，现在使用的仅仅是J1.0丰富的函数库和后端了。当然，若安装了一些新的组件，亦可不经分离的前端而直接使用。

kolidon将致力于J1.6性能提升的研究。