CMS漂流

WEB服务器当然很多。
张宴同学对nginx的研究让我领悟了应该抓住好机会来出名上位。
但是，这个会不会是一个机会？
——G-wan，直接使用原始C脚本来处理请求响应的WEB应用系统（当然，系统会自动预编译它，一如Java虚拟机和.NET所做的那样）。 http://www.g-wan.com
并发连接数可达10几万的系统。
速度据称可与静态页媲美，简单页面生成所耗时间可以用100还是200CPU循环来计算的系统。
小至200K，一个下载包里同时有window/linux平台执行文件，免费的系统。
 
我下载下来，安装，试了它们的demo。也试着vi了一个C文件放进去，果然很好很强大。
C脚本不用编译，看起来，似乎比PHP脚本快得多，特别地，受限于PHP和服务器间，及PHP本身的模型。普通server单机每秒500-1500请求似乎是极限。
 
那么，这么棒的一套系统，为什么它没有流行？出来也有好几个月了，竟然没有张宴2号同学来介绍它，试用它。
如果我们忘了CGI是怎样没落的话，看起来 G-wan声称已经解决了这个问题。
唔，C，这看起来不是个问题，大量人使用C。
 
但是，kolidon发现，函数原来好少，库原来也很少（虽然官方说放dll进去就能被使用，但我放了个pdflite进去，呼呼，使用不了）。
这个平台上的C，比PHP快400倍，比C#快5倍，比Java快8倍，我强烈相信。——但是，没有常用函数怎么办？怎么做快速开发？没有包和面向对象怎么办？怎么做企业级开发？
我不想每天25-30行代码地去写。我想每天200行代友。
我不想错过wordpress还有joomla还有drupal还有jeecms还有dotnetnuke。
 
不过，转回来，很多公司发现nginx/php/membercache/mysql的链条中，PHP才是最弱的一环，因为它在请求处理能图上差了一个数量级。
于是他们构建了自己的方案，来替代php做脚本处理。有更多，有了自己的memcache变体。
那么，如果用G-wan，会怎样？专用来处理切割困难、逻辑相对简单但耗时的大请求代码代码？
听起来，似乎是个好主意。
但是，就如某些人在PHP里掺Python还有scala/java一样。把我们的服务器平台搞得这么复杂有什么好处？我们来看看这样一个系统：它混合了NetScale, F5一类的硬件平台，squid，nginx，还有apache，现在我们加上上G-wan。当然，有PHP，还有JAVA，还有Mysql，还有Oracle，我们的逻辑也有一部分在Oracle和Mysql里面，触发器，存储过程等等，SQL也是一种灰常重要的语言哦——虽然它们在不同的平台上有大不一样的面貌。当然，有时候，还有一些Python和Scala。
多么美好，从此所有人都有了饭碗。
多么恐怖，从此我们需要让更多不同经验的家伙在一个项目里面和谐相处并且进度上齐头并进。
不过，其实我一直疑心，不同的位置用不同的解决方案或许正是复杂系统所需要的。有时候技术人员需要把架构搞得更复杂一点因为技术已经成为商业模型中的重要组成部分了。外面太多人有了金钢钻准备复制商业模式，我们就整复杂点拼拼人品拼拼细节吧。
杯具啊杯具。泪奔呀泪奔。
ps: G-wan不是开源，这里的free是免费，不是自由，当然，更没有公开源代码。如果开源，这个东西确实会，很好玩。

kolidon原作于2009年9月24日
1. 模板一致性 此问题并不是指模板风格和CSS一致，虽然这也很重要但是并不困难。Drupal中模板的问题在于因为系统模板的灵活，模板很难集中控制。即，模块中代码未模板化，或模板置于多个目录位置。
习惯以自有框架特别是某一种特定模板方案比如smarty一类，并且对模板进行集中处理的团队，转入Drupal后往往会对此迷惑。
实际上，这个问题是一个技术问题。
实施中解决办法是：制定出团队自己的模板命名，控制规范并不断修订完善。在每个项目中，对模板、自定义模板函数、自定模块中的模板以表格视图进行跟踪。
虽然Drupal系统提供了大量可能的模板化实施可能性，但对此系统了解越多，越能发现最简单的往往是最可靠的：仅使用模块内模板结构+模板目录内统一控制。
2. CCK及Views的使用
我们发现，基本上所有情况下Views殾能满足我们的需求——如果善用其Api文档的话，kolidon所在团队亦在学习如何将更多block也Views化——当然是不是一些其他页面也Panel化就有待考虑了（因为莫须有的性能问题）。
但我们偶尔会需要添加自定义的扩展模块来对其功能进行更改或扩展。
3. 权限问题
我们有时会需要在term页列出所有文章及其teaser但一个常用模块Content Access可能阻止那些无权限的文章出现在此页面，而此模块可能在其他页面会能用到（当然若不使用此模块此处不会用问题但会对项目其他需求造成不便）。
此时我们常做的时完全放开此content type的权限改由自定义模块来控制其全文存取。
4. Input format
输入格式对不同roles的授权也是需要较长时间试验才能获得满意结果的位置。
5. 开源模块质量
开源模块并非拿来就能用，最好看看其是否对性能造带来多大问题：比如某个模块og content admin就可能是一场华丽的性能灾难。
6. Menu及Breadcrumb系统
这个不用说，在任何系统中都是重中之重。若你使用了大量的第三方模块，然后又使用了大量的自定义模块，然后又企盼能将它们无缝组合起来：指的是在外部表现、菜单和Breadcrumb上的完全按业务需求而非模块的目录和自命名结构，那么，多考查几种相关模块，再多花点时间反复试验以便最终熟练吧。
7. 请尊重garland模板
这套模板，实际上，已经帮助我们完成了任何自定义模板工作的80%。所剩的唯有考查是否需要新增area，对原style.css作何种重规划和改进了。但对其整体结构的改变，试过后才会知道，意义不大。
8. locale问题
多语言在任何系统中都会是一个问题，kolidon并不认为Drupal在解决此问题上就已经完美了。
如果你仅仅是需要开发一种特定语言的系统，那么事情不会特别复杂（虽然也会出现一些莫名其妙的问题需要耗费大量时间去调试，比如关闭原生的English时你会发现部分页面会变成blank）。若需要开发多语言而且需要它们能正常切换，那么，诸天神佛保佑，但愿你的团队中有人研究过所有源代码，对这一部分的系统实际有深入了解并随时愿意解决各第三方模块中可能出现的语言问题。
9. Messaging和Notification
这部分也很好玩，如果你花了很多精力玩转了的话，另外，当然Cron不会是一个大问题但同样需要我们保持关注。但是当Messaging、Notification与Locale问题纠缠在一起，特别是不同的用户需要不同的Messaging的时候，我不知道它们是不是仍然让人喜欢。:-)
10. JS问题
如果团队中没有人精通JS，那么至少需要了解Jquery的用法和Drupal的JS框架。上天保佑，这么多Js不会产生冲突。
11. 性能问题
这个实际上如果没有太变态的第三方块的话，不会有什么问题，但若对性能要求较高的话，在登录状态，会需要所有人来贡献智慧以便解决周边的性能问题比如数据库、Gzip压缩、图片大小、背景图片或装饰图片数字，Js性能等等。最后，你会发现，转了一圈，回来了——我们终将面对的是登录状态下的Drupal核心的性能问题。若到了这一步，基本上，团队就开始专业起来了。

最近和朋友合作做了dedecms的一项目，颇有感触。 国内有想法的家伙其实是蛮多的。
一套好的CMS，特别是一套要在国内流行的CMS，几个因素非常重要：
1. 规则简单的，可扩展的模板系统，既支持模板单独定义，亦支持模板通用化（首页、频道首页、栏目清单页、文章页、专题页五个即够） 2. 静态页面生成、未生成静态页面时的预览功能 3. 动态建立内容模型(model)，如产品、软件、视频、图片等需要的信息有所不同 4. 其他如多级分类、对文章的不同标记（推荐、加粗、头条、图片、跳转等） 5. 配套的其他功能如广告、会员、图片水印、附件管理、数据库管理等。
我们分两次，每次半天，挂完了一个四屏长的页面加六七个三屏长的频道页，加栏目清单页和文章页。这在以前是无法想像的（JEECMS除外）。
另外，我们还对专题功能加装了一个插件，实以现对专题的各个节点分别列出文章清单。只需要taglib文件夹中放置一个myspecnote.lib.php的文件即可实现myspecnote的新标签。
{dede:myspecnote notei=somenote  }-----[field:arcurl/]------{/dedea:myspecnote}

若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 [...]

Drupal 是top1的php开源CMS（当然投票的应该大多是技术人员）。
好处在：
1. 比zend framework或cake php一类的纯框架多前后台；
2. 比Joomla这样的庞杂系统的代码基要简单。
问题在：
更适合程序员做CMS的主结构，做社区或做中等规模系统比较好。不适合普通用户的快速建站。
美国政府最新的救市计划，recovery.com，就是用drupal，而似乎美国总统的官方网站，也是用的这个。
如果开发框架是程序员的刀枪匕首的话，那么对PHP程序员来说，Drupal可以是第二种武器。
第一种武器，仍然是语言本身及各机构自己积累的各种开源组件，代码片断——对大型应用来说，架构本身将产生相当的价值，那么这个架构肯定是有特色的、与系统本身完全匹配的，一个词：自己的。
更重要的是：性能。