Java学习笔记一JSP一
JSP和Servlet的本质是一样的,因为JSP最终必须编译成Servlet才能运行,或者说JSP 只是生成Serv let 的“草稿”文件。DefaultServlet新建一个动态web工程,只是写了一个HTML,没有编写Servlet,甚至一句Java代码都没写。但是启动Tomcat后我却可以通过浏览器访问到刚才编写的haha.html。这是为何?对于像Tomcat这样的Servlet容器..
JSP的特点是在HTML 页面中嵌入Java 代码片段,或使用各种JSP 标签,包括使用用户自定义标签,从而可以动态地提供页面内容。早期JSP 页面的使用非常广泛, 一个Web 应用可以全部由JSP 页面组成,只辅以少量的JavaBean 即可。自Java EE 标准出现以后,人们逐渐认识到使用JSP 充当过多的角色是不合适的。因此, JSP 慢慢发展成单一的表现层技术,不再承担业务逻辑组件及持久层组件的责任。随着Java EE 技术的发展,又出现了FreeMarker 、Velocity 、Tapestry 等表现层技术,虽然这些技术基本可以取代JSP 技术,但实际上JSP 依然是应用最广泛的表现层技术。
JSP和Servlet的本质是一样的,因为JSP最终必须编译成Servlet才能运行,或者说JSP 只是生成Serv let 的“草稿”文件。JSP 的本质是Servlet (一个特殊的Java 类〉, 当用户向指定Servlet 发送请求时, Servlet 利用输出流动态生成HTML 页面,包括每一个静态的HTML 标签和所有在HTML 页面中出现的内容。
由于包括大量的HTML 标签、大量的静态文本及格式等,导致Servi et 的开发效率极为低下。所有的表现逻辑,包括布局、色彩及图像等,都必须相合在Java 代码中,这的确让人不胜其烦。JSP 的出现弥补了这种不足, JSP 通过在标准的HTML 页面中嵌入Java 代码,其静态的部分无须Java 程序控制,只有那些需要从数据库读取或需要动态生成的页面内容,才使用Java 脚本控制。
从表面上看,JSP 页面已经不再需要Java 类,似乎完全脱离了Java 面向对象的特征。事实上, JSP的本质依然是Servlet,每个JSP 页面就是一个Serviet 实例一一JSP 页面由系统编译成Servlet, Servlet再负责响应用户请求。也就是说, JSP 其实也是Se叫et 的一种简化,使用JSP 时,其实还是使用Servlet,因为Web 应用中的每个JSP 页面都会由Serviet 容器生成对应的Servlet o 对于Tomcat 而言, JSP页面生成的Serviet 放在work 路径对应的Web 应用下。
详细内容查看:JavaWeb一JSP简介
JSP内置对象
JSP 输出表达式
使用输出表达式的语法代替了原来的out.println输出语句,由此可见,输出表达式将转换成Serviet中的service方法里的输出语句。
JSP 声明
JSP 声明用于声明变量和方法。在JSP 声明中声明方法看起来很特别,似乎不需要定义类就可直接定义方法,方法似乎可以脱离类独立存在。实际上, JSP 声明将会转换成对应Servlet 的成员变量或成员方法,因此JSP 声明依然符合Java 语法。
。打开Tomcat 的work \ Catalina\ localhost\basicSyntax \org\apache~sp 目录下的declare_jsp.java 文件,看到如下代码片段:
由于JSP 声明语法定义的变量和方法对应于Servlet 类的成员变量和方法,所以JSP 声明部分定义的变量和方法可以使用private 、public 等访问控制符修饰,也可使用static 修饰, 将其变成类属性和类方法。但不能使用abstract修饰声明部分的方法,因为抽象方法将导致JSP对应Servlet 变成抽象类,从而导致无法实例化。
打开多个浏览器,甚至可以在不同的机器上打开浏览器来刷新该页面,将发现所有客户端访问的count 值是连续的,即所有客户端共享了同一个count 变量。这是因为: JSP 页面会编译成一个Servlet类,每个Servlet 在容器中只有一个实例:在JSP 中声明的变量是成员变量,成员变量只在创建实例时初始化,该变量的值将一直保存,直到实例销毁。
DefaultServlet
新建一个动态web工程,只是写了一个HTML,没有编写Servlet,甚至一句Java代码都没写。但是启动Tomcat后我却可以通过浏览器访问到刚才编写的haha.html。这是为何?对于像Tomcat这样的Servlet容器来说,任何一个请求的背后肯定有个Servlet在默默处理:
所以这次也不例外,肯定也有对应的Servlet处理了本次请求。既然不是我们写的,那只能是Tomcat提供的。查看Tomcat下的conf目录,除了我们熟悉的Server.xml,还有个web.xml。
不错,我们每个动态web工程都有个web.xml,而conf里的这个,是它们的“老爹”。它里面的配置,如果动态web工程没有覆盖,就会被“继承”下来。我们会发现,conf/web.xml里配置了一个DefaultServlet:
JspServlet:JSP的卸妆师傅
我们都知道JSP是“化了浓妆”的Servlet,但是好不容易伪装成了一个JSP,是谁帮它卸妆的呢?另外,大家仔细想想,一般来说JavaWeb阶段我们访问资源有三种“形式”:
localhost:8080/demo/AServlet:很明显,我们手动写了一个AServlet处理它
localhost:8080/demo/haha.html:虽然我们没写,但是Tomcat自己准备了DefaultServlet
localhost:8080/demo/index.jsp:我擦,谁来处理?
对呀,细思恐极,这*.jsp的资源,谁来处理?其实就是JspServlet。它的作用简而言之就是:首先,根据请求路径找到JSP;然后,将它“翻译成”Servlet。
刚才带大家看conf/web.xml时,我把它隐藏了,因为同时讲解DefaultServlet和JspServlet会比较乱。强烈建议大家现在暂停一下,打开本机的Tomcat找到conf/web.xml看一下。下面是JspServlet的配置:
所以最后总结一下Tomcat处理请求的几种方式:
更多推荐
所有评论(0)