Points：
- 回顾结构与表现分离
- 让html标签回归本位
- 页面内容的组织管理(开发流程中模板化工厂的初步构想)
结构与表现分离
先来点老生常谈，这里所指的结构与表现分离，是让表现和代码结构接近无关，也就是html标签里不再看得到与表现相关的任何东西。表现形式全都通过引入的css样式表来实现，而html>body中的标签结构只描述一个web应用的各个模块的层级关系。甚至更极端的状态，标签上所用到的id和class属性也仅仅只跟行为即页面交互相关，几乎不再为了一个纯表现的因素而定义id或class。
强调一下，基于html的web应用中，结构最大(因为是上天安排的，所以最大嘛，呵呵～)！包括前端和部分后端，前端自然不用说了，行为表现都依赖于结构。而后端的部分，在非纯ajax交互的应用中，后端与前端的html结构还是有交叉点的，用于生成一些内容呈现。但是，在这里仍然是结构最大，因为所要呈现的数据都是依赖于html结构的。一旦结构定义好，就不能再改变(设计好的可自由增删的部分除外)。
不过关于结构最大，还有很多话说，这里就不展开了，下次讨论～。
让html标签回归本位
追溯国内对html标签使用习惯的变迁，我认为可以分为几个阶段：文档时期；前div时期；table时期；后div时期；前语义化时期；后语义化时期。
解释一下：
文档时期。正如html的本意，超文本标记语言，最初期的html只不过是用于网上的简单文本交换。随着布局需求越来越复杂，html标签被当时应该称之为hack为布局的也越来越多。发展到今天，大家也看到了，html不知道产生了多少经济价值。
前div时期(可以说table早期同步)。据我所杜撰，那是一个混乱的年代，html上可以使用css了，mm的dw普及程度超过ms的fp了。上面有一个很有趣的布局功能——层，再加上视图里的那个可以拖动的小标签，造就了满屏幕都是绝对定位的层布局的网页。只不过那时候很多人对位置控制的都不精确，以至于那个年代的网页相当之丑，代码冗余也是相当恐怖。其实有时候我还挺想回归这种模式，应该是由于做多了Flash，里面的mc都是相当于绝对定位和相对定位的层，但毕竟html和flash不同。
table时期。与早期的div同时处于布局方式的摸索时期，但是发展的很快，也越来越成熟，最终取代了前div时期。本人当时是偶然打开了网易的首页代码，发现原来网页原来是这么做的——无数的表格嵌套在一起，通过cellspacing和cellpadding以及align来控制布局，瞬间转到了一个新的方向。于是，后div时期之前，可以说我用dw拉表格也是相当熟练的，而且都精确到象素。
后div时期。div还是那个div，只不过在w3c标准组织大旗一挥之下，无数的“做页面的”开始用css来控制页面的显示样式，页面中table几乎再也见不到，连数据表格都被一些css高手用一堆其他的标签hack显示出来。这个时期我经历的很短，当然不是自夸，也干过一个页面里面什么都用div来写的事，但是醒悟的很快。过后只承认这项技术叫html+css或者xhtml+css，而且坚决bs那些说div+css的人。不过要承认，后div时期是一步积极的进化，也为前语义化时期奠定了基础。
前语义化时期。现在可以说就是这个时期，语义化，让html标签又回归了当年文档时期的用途，该是什么样的结构，就用什么样的标签，比如标题用h1-h6，列表用ul ol li，内容段落就用p，原来被一帮人hack过的数据表格还是应该用table。于是大家开始发掘html里的各种标签，我也发掘出来一些并形成使用习惯：导航菜单用menu li，树形目录用dir li，表单的按钮用button，而div仅仅用来做为区分模块关系的结构。这是个和平大发展的时期，不过我们还是不得不用一些span+class来解决文本的显示样式，但在很多人看来，这样已经够好了。
后语义化时期。我脑子里滋生出一些想法，于是杜撰出了这样一个时期。不知道现在是否已经存在，也不知道是否有人和我有共同的想法。出于w3c的不推荐列表考虑，我们放弃了<font><sup><sub><b>……等等文本样式标签，取而代之的是清一色的span+class。但我现在的想法更为极端，我认为这些文本样式标签也应该回归本位。既然html定义了这些东西，使用起来又简单，在复杂的文本中使用这些标签非常方便，为什么还要因为“前语义化”而对结构中增加只为了表现存在的id或者class呢？这样也就回到了我们结构与表现分离的出发点，至少我认为减少这些不必要的id和class定义是非常惬意的一件事情！尝试过开发富文本编辑器的同学应该知道，js的添加样式的命令生成的就是这样的文本样式标签。文本样式标签非常简单易学，这样页面内容可以直接交给内容主管去添加修改，而他不用学会复杂的css，也不必每次改动都来找前端工程师来改css。我们的css文件将主要存储页面布局和文本基础样式。
页面内容的组织管理——开发流程中模板化工厂的初步构想
这样能够降低各个流程之间的耦合，也减轻了各方的压力。于是又引出一个新的概念，内容的组织管理，可以交给内容主管，并使之模板化。我的构想是，将页面中的内容文字和图片部分用一个模板变量(类似于smarty的思想)替换，比如：
<img src="xx.gif" mce_src="xx.gif" />新闻标题
替换为：
这只是一个范例，可以想出更多更好的模板变量组织方式。然后这段代码将会通过一个工厂组装上线，将里面的变量替换为模板里的内容，静态的就是html内容，动态的就是生成html内容的代码(或者java标签库等)。如果做这样的改变以后，在信息架构的流程里就可以确定所有页面的结构，那么从一开始到最后整个设计开发流程中我们最大的这个html结构都不再会发生改变，或者只是略微的改变(当然这是理想状态，没人可以保证这样做)。如果要发生改变，那么就要重新走一遍流程。
我构想的整体产品流程(“|”代表并行)：
- 产品设计
- 信息架构
- 交互设计|数据库设计|模板变量设计
- UI设计(开发)|交互开发|后端模板开发|内容编辑
- 工厂机器装配模板|(UI开发)
- 测试
- 上线装配(代码压缩优化)
- 上线
整个开发流程从串行开发或者说小并行开发(UI设计和后端数据库及功能可以同时)变成了大并行开发。产品经理与设计师，工程师等确定了方案后，共同协商信息架构和交互设计，并完成对页面结构的确定。之后就行程了多个分支，UI设计师在依据结构设计的同时，前端工程师可以先开发交互模块，设计结束再完成设计稿实现，(极端假设一下直接让UI设计师去完成css表现，不过几乎没有可能性)；后端工程师也不用等待前端的页面，只需要根据需求开发相应的内容呈现模板变量内容；同时内容主管也可以加入进来，随时更新要呈现的内容；质量监督人员也不再因为页面结构频繁改动而增大测试压力。
最终，至于这样的开发模式是否合理，也需要我们进一步讨论，并在项目中实践来得出结论。
Posted by mytharcher at 23:21 in web技术.
Comments: 5
