xml

1、我用HTML进行设计

曾经我以为我蛮特别的，我喜欢用记事本来写很简单很简单的HTML。而且，我看的关于网页的第一个教程也就是教你<h1>啊这些标签的教程。相信那个著名的教程，很多人都有看过。只是很多看过了之后不一定会自己去手写这些代码，只是知道frontpage这样的工具背后的原理就好了。
但是时间久了还是觉得蛮累的。因为我写代码的时候毕竟是要靠自己的大脑去想象最终的外观会是什么，所以有的时候还是蛮想去用Dreamweaver这样的工具。也难怪那些所见即所得的工具会有那么多用户了，因为写的时候就直接看到了最终的呈现。手写代码的时候，如果遇到了重要的内容，我会用<font>这样的标签特意去改变一下外观。遇到了列表的内容的时候会用<ul>啊这样的标签，产生1234的标号，或者一个个的圆点。其实有的时候觉得html挺简单的，因为标签的数量很有限嘛。

2、我使用HTML的表格

HTML的表格是很有意思的东西。当你遇到了要列表的东西的时候，如果是没有表头而且是一列的时候，你可能会用<ol>这样的单列。如果是两列，可能就会用<table>了。而且用起来也不是很复杂，<tr>就是开一行，<td>就是一列。当然还有很多种排法了。基本的也就是分方格，然后放东西。表格有趣的地方是，你设计form这样的东西的时候也会用表格。虽然每个单元格的内容之间没有什么意义上的关联了。不像你的成绩单列表那样，数学成绩一列，语文成绩一列。在form中使用表格仅仅是为了最终的版式上的问题。利用单元格把form中的元件进行定位。后来表格的排版作用用到了整个页面的排版，而且越用越复杂，表格加表格。直接导致了我这样手写代码的人无法去修改，去编写这样的页面。一度让我很伤心，觉得这个世界被Dreamweaver这样的工具的使用者掌握者，因为只有利用所见即所得才能够去设计这样外观丰富的主页。

3、我还用过css

css是让我激动的东西。我承认这点。我曾经梦想，我写网页的时候只要把每块内容指定好了class。以后要改变网页的外观就只需要把css换调就可以了。而且css可以是内含的也可以是外部用<link>链接的。我要把网站改版把css的内容换一下就可以了。而且css还有import，利用它我还可以在网站的每个目录下都放一个style.css，然后利用import包含站点的样式表。这样每个网页就不用..这样的目录选择符来选择在父目录中的样式表了。这个特性着实让我很兴奋。我的梦想越来越清晰，就是有朝一日，我写的网页能够很轻易的更改外观，而且编写的时候再也不用自己去使用<font>这样的标签了。

4、javascript也是让人好奇的东西

我相信网络发展还不如现在这么发达的时候就开始设计网页的朋友，一定对于各式各样的javascript非常熟悉。比如跟随鼠标的星星，跑马灯之类的东西。javascript设计出来是为了实现客户端的一定交互性的。javascript之所以能够交互是因为，它能够通过DOM操纵你看到的html页面，而且能够通过html元素中的事件属性得到你的输入。因为javascript能够通过DOM把html的页面进行改变。这个性质其实也让我激动了好久。比如leoboard的最新帖子这样的信息，就是通过一个<script>的链接，链接到一个cgi上面，它产生的就是一段js脚本，通过document的函数写出一段html代码。也就是说，javascript能够"动态"的产生html代码。由于javascript的这个功能，我又开始做梦了。希望能够整个网站都是通过互相包含的javascript组成。我把我的内容都写在javascript的变量之中，然后通过一定规则组合通过DOM的函数把内容以一定的模板风格写入到最终的html输出之中。

5、再闻css

一开始听说css，也许那个时候还是css1的时代吧。只知道css能够设定一定元素的外观显示，比如字体啊，空白什么的。关于css的排版功能一概不知。第一次做css的梦的时候，其实就是因为要把html进行排版控制，不得不用很多的table这个原因破灭的。所以当我知道css的功能很强大，可以进行各种版面控制的时候，就又开始做梦了。把内容按照其性质放到一些<div class="...">这样的标签之中，用不同的css样式表，能够把这些div定位到页面的不同地方，而且显示也是不一样的。这样我就能够在写html的时候以任意的顺序来写，只管内容。而css会根据你对内容的描述（class是什么）把内容进行定位排版和显示。所以说，以前我知道的css只把元素的内容和显示分开了，但是元素的位置还是与在源代码中的位置相关。而现在知道的css，能够让元素只管自己的事情，告诉css自己是什么（class是什么），不用再考虑自己在文档中的位置了。这样不就实现了内容与表现分离了吗？不就是我等用记事本写网页的网页设计者追求的吗？

6、内容与外观分离

我相信这句话很多人都听说过，梦想过。我的梦从模糊，到清晰，一直都在想着有朝一日我能够只管把我要传达的内容写下来，让其他的人来给我排版给我定外观。It is a Dream。我们只从一个网页设计者的角度，而且是一个普通网页设计者的角度来谈这个问题。不要把什么中间件，应用服务器什么程序高手津津乐道的术语来压"我们"。为什么要把内容和外观分离我相信很多人都有自己的体会。我的体会很简单。当年自己手写html的时候，我对我的内容很有信心，我知道我要说什么，我有内容。但是我对于如何排版很没有信息，我想让别人，或者自己以后来把内容进行排版。但是事情是很让人失望的，我基本上只有两个对策。把内容的格式变得简单得不能再简单，只是html的最基本元素的线性排列。除了<p>就是<p>这样的页面，朴素得不能再朴素。要么就是设计一个很好看，很复杂的页面。我自己手工的把内容粘贴到页面的模板之中去。如果有很多类似的网页，还要保证它们的风格是一致的。如果每个页面还有到其他页面的链接，比如是上一页，下一页之类的，It is a nightmare。把内容与外观分离，就这样成为了我16岁的梦想。

7、perl，php，asp

我很坦白，我从来没有用过jsp，我不喜欢java提供的那些东西（请不要因此骂我浅薄，我知道它们的商业价值，但是现在仅仅是说网页设计）。按照顺序，我用过的是这么三种网络脚本。perl是我接触的最早的一个网络脚本，那个时候一般都是用cgi这个名字。后来我有遇到了php，最后才是asp。这里我只是谈网页的问题，不涉及到这些网络脚本怎么实现网络的交互的。也只是就着网络脚本，说说它们怎么又能实现内容与外观分离的。而且这三种虽然在访问文件，访问数据库，使用模板，产生html输出各个阶段和模块上各有不同，但是原理一样，方法相似，所以通称网络脚本。网络脚本是让我激动的东西，而且同样作为engine驱动着很多现在正在运行的网站，比如经典的LAMP组合。它们关键的地方是能够产生html输出。因为html不再是你自己手写的了，所以不需要经过你的手就能把html的输出产生变动，这样就有灵活性。为了文章能够分出更多的节，我按照我个人的认识顺序来看看网络脚本使用

8、网络脚本和文件

我最先看到网络脚本的使用，是leoboard这样的cgi程序，它使用文本作为数据的存放媒介。数据来源是文本，然后cgi中的perl程序会对文本进行解析，然后把解析的结果可能会放到变量之中，最后变成html的输出。这里就是通过cgi程序作为中介，把文本的内容表现到了html之中。

9、网络脚本和数据库

后来我才看到了网络脚本和数据库的连用。经典的搭配有php+mysql和asp+access，我都有用过，不过都是很简单的。把数据储存在数据库中好处当然是多多，专业人士可以有很多事务啊之类的术语来描述其好处。不过显而易见的是，储存和获取的方法是标准化的，通过SQL嘛。而用文本作为存放媒介，文件格式以及解析，还有文件的完整性，容错这些都需要网络脚本设计者自己来控制，虽然很自由，但是更多的是劳累。同样，一种脚本有自己的一种格式，多浪费。要换论坛程序这样的情况出现的时候，又需要了很多麻烦。

10、网络脚本和模板

我记得当时我学asp的时候，很多文章就是这么介绍的。asp能够夹杂在html的代码之中，可以很方便的使用。而我使用perl的cgi的时候，很多程序又是使用满是$xxx的模板来做html输出的。这个时候，我就想who is better？模板我还是蛮欣赏的。初级阶段的模板就是很多以前的cgi的网络文章程序中的那样，在html中放perl的变量名，然后最后输出的时候做一个替换。现在的模板当然要复杂好多，理论也很多。但是，我们可以看到的一点是模板做到了"把业务逻辑和表现逻辑分离"。一般模板和脚本的关联就是通过一些两方面都知道名字的变量或者数组。然后脚本在变量中预先把内容存入这些变量之中，模板再把变量和数组中的内容提取出来插入到html之中。由于模板大部分是由html组成，所以比较适合给设计人员来设计。而且脚本的任务也就仅仅致力于从数据库也好，文本也好，这样的数据源中取出内容，进行一些加工，然后存入到变量之中。至少让脚本程序员免于考虑最终的外观问题。

11、网络脚本的时代

我们现在基本上就处在这么一个时代之中，大部分的页面已经不是手工编写的html了。而是由网络脚本动态产生的。方法步骤都是类似的：数据源+网络脚本+模板=页面。似乎故事已经到了终结了。因为美梦已经成真了。利用数据库中存放数据，模板来控制显示，网络脚本进行一些计算和沟通工作，内容和外观分离的梦想已经实现了。而且，现下的很多现成的程序，一些CMS（内容管理系统），你直接在服务器上安装好，就能够享受其便利了。但是，我们还有更多选择。

12、XML的登台

XML应该不是什么陌生的东西了。如果你不知道，说明你可能已经很久都没有关心过网页设计或者说是计算机这个行业了。XML的好处，长处，已经被说烂了。我就不多说了。
我把XML分为两类：作为数据或者文档的XML，以及功能性的XML。这个分类是我自己下的，功能性的XML指的就是HTML，SVG，MathML这些。可能SVG什么的你不了解，但是至少HTML你知道吧。关于HTML也是XML这个观点，你应该听说过。HTML为什么被我说成功能性的XML呢？因为如果你浏览器为观点，它认识HTML，它能够把HTML标记的能内容作出显示。而如果是一般的XML，它就不认得，如果是IE会调用内部的一个显示XML的模板把它显示出来，但是有的浏览器就不会。也就是说，一般的XML其中的内容元素，对于浏览器来说它是不知道什么意义的，而HTML的元素是对浏览器有特殊意义的。同样，SVG这些XML也是这样，虽然标准仍然在制定之中，浏览器对它的支援还需要一些插件。但是SVG的基本结构不会有什么变动了，它就是通过标签的标记，通过浏览器的读取产生二维的图像。关键的地方就是，浏览器认得SVG中的元素，知道它的意义，并且能够作出显示。
自然，对于浏览器没有特殊意义的XML就是文档数据型的。把XML分为文档为中心和数据为中心的这种分法是非常常见的。关于这个话题，我在后面继续说。

13、HTML作为一种功能性的XML

我现在把HTML完全作为一种表现语言，它的唯一功能就是把内容作出显示。也就是我把在HTML中表现内容的语意这个梦想给完全放弃了。HTML就是一个功能性的XML，它的目的就是让浏览器显示。要把内容和表现分离，我就是要从别的数据源中转换到HTML。那是不是CSS就多余了？当然不会，css的目的是帮助HTML更好的表达如何显示这个要求。也就是XHTML+CSS共同表达的一个目的，网页的外观布局。它们的目的是一致的，而不是我以前想象中的HTML表达内容，css来表达外观。而且CSS的存在，能够表达更加精确更加丰富的内容，而且比用table这样的表格排版更加简洁明了。

14、XML作为HTML的源头

我把HTML表达网页的内容这个想法给放弃了之后，很自然的想法是把XML作为HTML的数据来源。但是这并不是很常见的做法。更多的做法是，利用数据库，利用文件然后用网络脚本进行提取，然后可能还要通过一道模板，直接产生HTML。其中并没有XML的位置，那么到底在产生HTML的过程中需不需要XML呢？
现在问题已经很明白了，HTML完全作为一种表现语言。焦点是对于HTML从何而来这个问题。务实的态度是尊重现有的解决方案，而且它们可以做得很好。这里只是对于XML能够在产生HTML的过程中的什么阶段进行参与工作，进行一些个人的看法的探讨。

15、XML直接产生HTML

这个可能是很多人头脑中首先想到的办法。利用XSLT，把XML转换成HTML。而且关于这个，我将在文章最后，给一个我个人的全面的想法。
我觉得利用XML产生HTML，主要是用在小型的纯发布的场合（比如个人主页），因为对于XML文件的更新和删除这些，并不是很完善。而且即使是使用XML数据库，也不能胜任大型的场合。而XML更多的是作为中间数据

16、有数据库产生XML然后产生HTML

这可能是一个很好的方案。只是在现在看来有一些多余。因为网络脚本从数据库中提取了内容之后，直接就产生HTML了，或者调用一个模板也把HTML产生了。如果其中在多一个产生XML的过程，还需要再编写XSLT来产生HTML，让人觉得没有这个必要。

17、XML与数据库

很自然的，就延伸出了一个讨论就是"XML与数据库，用哪一个？"。其实这个问题之所以成为，我认为是XML的发展不成熟。XML有其结构和功能上的优越性，但是同样带来了很大的复杂度。对于XML进行查询，就比对于结构简单的数据库查询复杂变数大很多。同样，XML的表现力也要强很多。另外还与XML的两个用法有关，XML一方面可以用作以数据为中心，比如网站的客户订单。这和关系型的数据库的特点是一致的，每个table的项是固定的，数据都是类似重复的。而XML同时还能用作文档为中心的，比如你写一篇文章时，用XML对文章进行标记。这样使得标记出现的位置，以及上下文就变得非常重要。
所以关于，在什么场合下用XML，什么场合下需要XML这种问题，很难有答案。至少有一点，随着XML技术的完善和被越来越多的人掌握，XML会在其适合的场合越来越多的使用。

18、XML与网站

如果仅仅是泛泛而谈XML与数据库，我觉得是很难定论。但是如果把讨论的范围缩小到网站，我觉得还是很容易得出答案的。对于交互性的场合，比如论坛，数据经常要更新，XML就不适合。对于发布性的场合，比如文章系统，XML就是一个很好的选择。当然还要考虑查询是否方便。以及XML适合描述松散的信息，比如站长信息这样的数据存放到数据库中显然是overkill，而放到xml中就比较合适。所以，我个人认为如果是个人主页这样性质的网站，使用xml是非常合适的。

19、在个人主页中使用XML

个人主页一般都是无法购买那种有网络脚本支持的服务器的，更不用说数据库了，这个是来自于现实环境的限制。个人主页的数据一般比较松散凌乱，而且文档比较多，比较适合XML来描述，这个是显示的需求。
所以综合了这两点，对于一般个人主页的站长来说，这样的组合方案是很不错的：
1、用XML来描述网站数据，用XSLT来做转换
2、注册一个免费的留言板
3、注册一个免费的BLOG
这样你就只需要一个HTML空间，同时又可以实现内容与外观分离，至少对我来说是一个梦想的实现。

20、最终实现指导

这个纯粹是个人意见，而且技术门槛相对比较高一些，估计没有人会采纳。
第一步：
描述你的网站内容。如何描述完全是你的自由，而且是否使用DocBook这样的东西来描述你的文章这样的东西也是你的自由。描述应该分布在很多个xml文件之中，可以利用XInclude技术，也就是利用<xi:include href='...xml'/>这样的标签把所有的xml逐级串起来，最终是一个site.xml。找到了site.xml，就找到了你整个网站的内容。
你可以不用xinclude，而只是简单的用一个元素记录下文件位置，然后在XSLT中用document函数读取也是可行的。
第二步：
描述你的网站的结构，也就是页面的信息。这个我是用sitemap.xsl来做的。最终产生的就是一个sitemap.xml。里面由类似这样的元素组成：
<page name="article1" template="article.xsl" output="article1.html" param="1"/>
这样有两个非常重要的作用，其一是能够让自动化的工具从产生的页面信息中提取内容，自动调用xslt处理器把网站给编译出来。其二是能够让页面索引到其他页面，比如你要在一篇文章的页面中链接到所属的分类的所有其他的文章，你就可以在sitemap.xml中提供出哪些页面是干什么的，比如所属分类是什么。然后具体page的xsl就可以在sitemap.xml中根据这些信息，然后找到页面最终写出超级链接。
第三步：
设计每个页面的xslt。xslt的输入有两个，一个是site.xml，另外一个就是sitemap.xml。从site.xml得到内容，从sitemap.xml得到其他页面的位置。
第四步：
利用你喜欢的脚本工具（设置是xslt+bat），自动化的完成整站的编译工作。你还可以提供选项选择编译什么页面。
第五步：
你也可以自己编写一个工具来实现新旧对比的ftp上传工作。

OK，对于网页设计的技术的我的思考就基本上告一段落了。
PS:很经典,每个学习WEB的人的经历的浓缩!可惜我还是不能完全的理解!!~~
努力中.........