1、风讯5.0似乎毛病很多。起初是看不起它的新编辑器把代码统统改写成大写，然后发现终极栏目页的排序竟然也会错，看来是增加的功能不仅没有修补老问题，反倒增加了新问题，干脆还是用4.0SP7。
2、修改部分敏感目录。将CMS执行SQL管理的两个致命文件DataManage.asp和DataSqlResult.asp删除。我不会在线运行SQL语句，而且这两个东西太过敏感了。
3、4.07的编辑器默认情况下将回车辨认为br，在\fckeditor\fckconfig.js中设置一下，搞成P就OK。
标签：CMS
搞懂“自由标签” SQL语句很简很繁很好玩
前几天把风讯的“自由标签”终于搞明白了：用一个向导式的方式，从新闻表和栏目表里查询数据，然后将数据按照自由的方式进行排列，并可产生循环、只生成指定序号，或者对字段内容进行截断。
自定义函数：循环内容{#…#}、不循环内容{*n…*}(n>0)代表记录序号、函数(#…#)；如(#Left([*FS_News.Title*],20)#)
目前还不知道他们是不是可以嵌套循环。以前自由标签总也不成功，就是忽略了这种关键性的风讯私有写法，使得结果总是为空。不是前几天看别人的例子根本就不会知道这种一句话带过的“帮助”在说什么。再说风讯从2006年以后就没有再更新过这类内容了。
自由标签的的好处是显而易见的，这种方式可以完全打破过去div、ul、li的束缚，使得FLASH幻灯之类的效果很容易实现。如果不掌握自由标签，就只有用系统默认的方式或者借助于符合标准代码的幻灯系统。
定的XSLT、SQL两本书还没来，“需要”就出现了。
今天准备将自由标签和自定义字段结合做一个效果，费了半天劲搞懂了SQL语句才发现：即使在数据库中直接写入查询语句，风讯自带的发布系统也不允许将新闻和栏目表以外的东西通过自由标签生成出来。这不得不说是一个重大遗憾。不过四个多小时的思考和仔细“研判”让我发现了sql查询的可爱之处。
以前我只晓得SQL可以从一个表中带条件的查询出字段数据，但是每本书对于SQL语句的介绍都是几页纸就翻过了，要么就是复杂得要命的一饼黑乎乎的代码，自从上次小山子给我写了一段查询重复文章内容的查询，我就彻底晕了。怎么在一个查询中查询两个表中的数据，在基础入门的例子中是不屑于写的。于是向万能的GK讨例子，我按照ACCSEE图形化操作的方式给他讲我的需求，结果写完了需求我自己也晕了。
通过仔细研读风讯向导生成的新闻表和栏目表关联查询语句，发现SQL的这种查询非常容易理解。首先查询语句中的字段要写全，也就是“数据表名称.字段名”用,号分割他们。在指定来源表名称时把所有表的名称写上，用,分割。
这时候执行的查询结果很可怕，两个表会把所有可能的匹配结果都输出来。所以SQL语句中重要的是后面的条件语句。多个条件语句间用“AND”链接，比如哪个等于哪个啊，哪个等于什么数值啊，完全不用管先后顺序，是不是跨了表，只要你把条件都写出来，那么结果就是你想要的，完全不用管他们的祖宗十八代的因果关系是怎么样的，而ACCESS的图形化界面下要实现跨表查询还要关联这个关联那个，麻烦得要命。怨不得SQL语句才是数据库处理的名门正派。
明白了SQL的这种工作方式，以前一些想起来比较头大的数据关联方式就变得非常容易理解了。
等书来了，要把所有的例子都操作一遍。这东西比较有意思。
没有任何理由升级到风讯dotNETCMS v1.0
风讯终于发布了dotNETCMS v1.0，并且同时发布了源代码。马上下载一个安装，试用几下就大失所望。
虽然风讯感觉上比动易速度快很多，但是功能上确实太轻量化了。
开放源码对于我来说没有什么意义，ASP代码勉强能看着眼熟改几下，.net源码给我基本跟没有一样。
再看网站的基础模型，一点都没有新意，完全就是用.net语言改写的ASP版，样式的建立和标签的建立就是改了下UI界面，其本质上与ASP版没什么区别。建立标签的部分加了个自定义样式的设计，可以避免让设计师在做模板的时候转晕头，但这也只是方便性上的改进，并没有实质性的变化。
采集这块也完全采用的是过去的方式，一点火花也没有。
表面上看，是免费版限制了自定义模型的功能，但是我觉得是风讯自己就没有搞出来，否则在自定义模型下这种采集功能一点用场都没有。自定义模型、流程在初期宣传中是.net的最大变化，但是现在看来完全不是那么一回事，在.net的比赛中风讯落后动易很多。
针对新闻编辑中远程保存的问题我做了个测试，虽然号称能保存SWF文件，但是我发现贴过去的源代码中SWF的地址竟然还是相对路径，保存了一下根本就无法使用，提交过程完全没有反映，就好像冻死了一样。
缩略图的处理也有很大问题，目前之能通过按比例和尺寸进行缩放，而不能裁切。动易的版本在这方面灵活很多。
其实IWMS在很早就实现了这些功能，而这些.net系统的后来者竟然还学得这么辛苦。小东西上做得很完善的IWMS偏偏又不大气，只能拿来做作个人知识整理。看来鱼和熊掌还是两码不能调和的事情啊。
还是花点心思给动易吧，至少在概念模型上他要强很多，开不开源对我来说都无关紧要啦。
修改风讯4.0SP5分页代码
风讯的分页代码有四类，三类是为终极栏目准备的，一类是为内容爷准备的。关键性的程序代码是在\admin\PublicSite目录下的Public_Function.asp文件里。
用记事本打开，取消“自动换行”，代码的层次有非常明显了。从Function Get_More_Page_Link_Str这行开始是处理分页的程序。很明显，Case 1、2、3代表了分类的三种分页方式，代码很简短，修改起来应该也很容易，但是似乎没有惹这个麻烦的必要，由于分页太长产生的问题可以用样式表来解决。
这三段代码过后就是内容页分页代码。很复杂，因为它有很多判断用来控制长度。这段改动较大。改动的目的是区分上翻页控制区、数字区和下翻页控制区，给他们加上ID，以方便CSS控制。
处理分页的最后一行我改成了这样：Get_More_Page_Link_Str=”<divpage_nav””>”&Str_Link&”</div>”，让整个翻页代码具有一个ID，以方便样式表控制。
在之前的改动中犯了一个错误：为了照顾内容翻页代码，我在这最后一段代码后使用了两个</div>结尾。内容分页是没问题了，但是所有的列表分页全错了，而且导致布局的DIV错乱。原来这个结尾的容器是所有分页代码共用的，所以一定要保持它的纯洁。
SiteFactory1.0试用手记（第二阶段）
逐步发现了动易SF的一些问题：
一、上传文件管理的问题
在文章被删除，并彻底清空回收站后，所带的上传图片不会被清除，上传文件管理栏目也没有清除无用文件的选项。长此下去，势必造成文件混乱和所占空间的加大。动网的IWMS.net从一开始就有这个功能，风讯的.NET正式版本也声称会做进这个功能，所以动易如果缺少这个实用的清理功能会是一个比较大的遗憾。
动易的管理员回复说内容之间可能有共用文件，所以不能在删除时清理，但是我觉得可以采取对照文件和内容字段中文件进行比较的方式进行无用文件清除。
二、采集项目的问题
当被采集地址带端口号的时候（比如http://192.168.0.1:8888）建立采集规则的时候取得地址和进入字段采集规则都会有问题。
动易管理员认为端口号的网站是特例。我觉得也有道理。
三、采集项目转移的问题
1、建立一个采集项目，并且顺利采集完一个栏目。清除采集历史记录。
2、复制这个项目，修改部分信息开始另外一个栏目的采集。
这时候会发现他似乎把老项目中的地址库给带过来了，重新采过一遍后才开始采第二个项目新加的地址列表，而且老地址全部失败。
通过“点击浏览”这些失败的地址，发现内容发生了一些变化，比如从原来的http://www.0791.net//html/2007-07/3848.htm 变成了 http://www.0791.net/html/html/2007-07/3848.htm 。
我想这可能是一个疏漏。
四、采集中，内容采集的“分页”栏目保存、修改会造成参数的混乱。
很简单的一个测试就能发现的问题。
内容页添加一个规则，并且指定翻页设置为从”源代码中获取分页URL”，随便写点什么，存盘退出。
立即修改此规则，再看”源代码中获取分页URL”中，什么都没有，所填的字符串出现在“从源代码中获取下一页URL”中。
幸运的是，如果第一次建立规则后不去修改它，他们一切工作正常，这个问题也许是载入的时候JS把文字填错了地方？
五、分页方式中有一种模式没有任何意义。
动易现在只是简单的把栏目批量分页的机制搬到了内容分页中过来。其实“批量制定分页URL编码”在目前来说是没有意义的，因为内容页的分页至少需要两个变量：一个是当前页面名称，一个是自动递增的数字，而栏目页只需要一个自动递增的数字就可以了。
建议用链接符的概念解决这个问题。以下URL为例子
http://www.xxxxx.com/news/888.html
http://www.xxxxx.com/news/888_p1html
http://www.xxxxx.com/news/888_p2.html
在这个序列中，URLhttp://www.xxxxx.com/news/888.html是中列表采集中获得的，所以在批量设置中就不考虑他，而是让使用者设置链接符为”_p”，数字id是从“1”到“2”，判断这个参数插入点的方式就是整个URL的最后一个.的左侧。
这种处理机制可以解决大部分的分页问题，因为现在的分页一般都是这么考虑：原始URL+链接符+参数+后缀。只要在这个模式内，并且ID设置范围足够大，就可以把所有分页信息通杀。
六、其他遗憾
SF自动下载功能只能采集图片，而不能处理SWF。这个功能在早前的IWMS中就有了，不知道风讯会怎么处理。
速度的体验非常不好，在AMD2200+的本机测试中感觉机器延迟现象明显，象是老迈的感觉，没有ASP风讯和IWMS的感觉好，生成的速度还可以，但是生成一个没什么内容的首页也要将近26秒就太过分了。
标签过多，而且没有什么解释，虽然可定制的能力非常强，但是……大部分看不懂，需要SQL和XSL的丰富经验。
风讯的采集实在太垃圾，不知道新版会做成怎样。等出来以后要做个对比看看。SF的感觉好像是个RC3，而不是正式版。不过风讯的RC竟然还有功能未提供测试，不知道是不是想做成精品.
认识XML+XSLT
尝鲜尝鲜，动易的采集不错，SF的感觉也不错，粗略使用了一下后就要关心模板和标签了。
动易原来的标签系统我非常不喜欢，看不明白（如果我那样也算看明白了的话，那就说明这种标签系统太单调了）。风讯的自由标签是不错，可是我一次都没用过，高新技术派不上用场，但是风讯在一般性标签中将样式和标签分开的做法我是很喜欢的。
动易SF的新标签系统应该说可以做到和风讯那样数据和样式表现分离了，只不过对数据库的表和字段要非常熟悉。至于SQL查询，反正我目前是不会用什么新奇的查询方式，嗯，不是“不去用”是“不会用”。谢天谢地，动易这次没有自己开发出一种私有的标签解释模型，而是使用了公版的XSLT，这是格式化XML的标准方法。这样的解释方式一来学习起来更容易，有更多的书可以参考，更多的人可以咨询，二来一举两得，熟悉了CMS，也接触了一门新科目。
按照动易SF的手册做了一下，感觉有那么点门道，但是还是太麻烦。无意中看见动易的手册建议用户用DW8来完成建立XSLT的操作，马上翻阅了下参考资料，DW8还真有这个可视化编辑功能。
简单的说，就是先建立一个XML（动易SF可以自动生成一个符合查询条件的XML)，然后新建一个XSLT页面（实际使用中可以是要选择XSLT片段），DW8自动要求绑定数据源。选定SF自动生成的XML文件。在绑定面板中将可使用的字段拖进来，并且快速选定需要循环的部分，“插入”XSLT循环语句，选中带有加号的节点。确定，存盘，一个可以使用的XSLT就建立好了。把这个XSLT应用到XML中去，只要打开XML文件，附加上XSLT这个样式表，存盘就好了。无论用IE还是FF打开XML文件，就能得到视觉化的效果。用FF的工具还能得到还原后的HTML代码，用这个代码做CSS样式将会更加直观方便。
接下来找点资料，争取把对字段数据的过滤转换搞明白。比如SF的时间字段就非常复杂，要得到指定样式的时间还不知道怎么办。
不过这已经让我很满意了，SF的可定制性的确非常高。等风讯出来了，要看看正式版的DC究竟有什么过人之处。