网站建设：对网站前台架构几点分析
回顾一下，我自己经历过几次转变。先是flash转html，纯flash是没啥意思的。然后是尝试纯xml/xsl，这种代码写出来很有成就感，但是直到今天，还是有浏览器兼容的问题，而且也不知道搜索引擎会不会索引它。再后来是html里面的div取代table，引入css2，的确灵活了，似乎一直没有像dreamweaver里面操作table一样方便的layout搭建工具。最后这波就是ajax了，突破了web体验想象力的边框，而且提供前后台通过xml中间层彻底分离的能力。总的方向是，数据和表现分离，前台和后台分离。
这个过程中我们解决了一些问题，比如页面写好之后可以通过修改css更换它的style，无需页面刷新就可以载入、保存数据，同时，也出现了新的问题，xhtml/css编写难度提高了，xhtml代码被js所取代，复杂的明显提高了，seo也出现了问题。
这些变化，改变了建设的工作流程和具体工作方式。原来做一个，策划好每个页面，然后美术设计，然后制作成html，然后嵌入脚本，如果这个时候需求变更了，就麻烦了，制作人员和开发人员会手忙脚乱的调整已经嵌入了脚本的html。现在，策划人员的工作首先就变了，原来死板的wireframe不适用了，我现在开始尝试用虚线框来区分一个页面中的多个表现阶段。页面制作出来以后可能也不是由制作人员首先做成html，而是前台架构师先设计一个架构，定义一些标准，比如用不用frame，地址栏如何在ajax下面随着页面变化而变化，如何处理后退，哪些模块的数据用ajax哪些需要载入页面，等等，然后在这个架构下，才开始页面制作，甚至跳过页面制作，js人员直接用代码搞定，页面制作人员只负责css。
说到这里，我还是对seo的问题念念不忘。有人说这是搜索引擎应该考虑的问题，我们走自己的路好了，我不能接受，因为我知道page rank上了8以后，能给一个带来40%以上的额外流量，这里还不算会有多少新用户会沉淀下来。所谓优化，就是一种迎合的心态，毕竟在这个阶段，互联网世界中搜索引擎?最大。这里我有一些思考，还没经过实践。首先是google sitemap，多少应该有点用途，不能太指望它;其次呢，是一种类似blogger.com的发布机制，再优化一下，加入realtime和archive的概念。最新发表的帖子可以立即看，用的是realtime模式，动态生成;过去的帖子在后台已经转变成静态页面了，属于archive模式，这样一来，把后台提供的xml数据显示为页面的工作就由前台js转移到了后面的发布server，很多关键的内容页面就可以静态化了。(页面中嵌script在apache下面运行的方案不做讨论，因为这样的方案支撑不了海量访问服务)
这样做会面临一个问题，如果用户修改了layout，一些div前后位置调整了，原来生成的archive页面不适用了，怎么办?可以先把archive清空，全部用realtime模式顶上，发布server闲的时候重新建立archive。嗯，似乎可以这样搞定。