我的web之旅（一）

在工作中涉及到了路由器web配置界面的开发，这里做下简单回顾。

下面介绍下我的web入门阶段。由于之前未接触过web，因此是零基础，需要一点一滴熟悉。

刚开始半月用来熟悉html css javascript 跟着w3school学习了web的基本东西，写了一个简单的页面布局。同时熟悉了httpd协议。这个期间也零碎的解决了项目上的一些很小的需求，总的来说，这个阶段打下的基础不算扎实。

然后熟悉项目框架**。说到**，让我想起了mvc（模型-视图-控制器）里的模型和控制器。感觉**主要起到的就是控制器和模型的作用。为什么呢？因为我们的**项目开发 web开发模式是cgi方式。

比如页面A的产生过程一般步骤如下（这里的**表示一种后缀名，框架只识别这种形式的文件）：

1 A_t.**  表示页面样式

2 A_js.**  集合了页面的js行为

3 A_**.** 表示页面的数据

**框架是以文件为单位来解析，这些文件都会经过脚本引擎来解析。所以后缀形式是统一的。这里的脚本引擎相当于是python中的wsgi.具体的是解析文件中<% %>里的内容。然后翻译成浏览器能够识别的格式。抽象点说，可以把**看做是一种脚本语言，也有他的语法规则。

它的优劣总结如下：

优势：可以用脚本实现任何功能

劣势：前后端不能分离，代码维护困难

这个过程可以参考《大型网站技术架构：核心原理与案例分析》一文：CGI程序在获得最大处理能力的同时，也给开发人员带来了麻烦：负责编写业务逻辑程序的程序员不擅长处理HTML，而负责页面构造的美工人员则对程序束手无策。同样维护这样的程序也是一个噩梦，业务代码和页面语法耦合在一起，让人无从下手。

一个页面的产生过程大概是这样了，如果是千千万万的页面呢？如何处理登录、超时、退出等等这些公用的东西呢？是不是可以把这些集中起来处理呢？答案是当然可以的了。

这就是框架的作用嘛。下面就来一一分析。

首先，我们看一下用户登录网站的基本过程。

登录----这个过程其实可以不是必须的，

浏览页面---这个肯定有

退出-----可以是直接关掉页面或者点击页面上退出按钮。

最后结合目前web整个框架来看下这个流程：

浏览器-------web服务器-------应用服务器

web服务器收到请求后，解析出当前要解析的页面，然后把页面路径传给应用服务器，应用服务器启动解析引擎，解析该页面，生成html文件流，传给web服务器。