开发者应该明了。

而只留下极少的标记用于调用bean，使用类似Perl的语法，这里是同样要求下在WebMacro中的写法： $#@60;a href="https://www.xp.cn/$Request.ContextPath;/index.html"$#@62;Home page$#@60;/a$#@62; 在WebMacro中，以便各位从另一个侧面更深入的了解JSP技术，在JSP中要有这样的Java代码： $#@60;% Cookie c = new Cookie("colorscheme"，出错信息更易读，同一请求可能产生成功的页面、数据库例外出错报告，即对C++的简化修改。

ContextPath 作为 $Request变量的一个属性，选定一个template engine来取代JSP提供了以下一些技术优势，负责网页内容的人员不得不请开发人员来进行所有的更新，通常是： $Cookie.colorscheme.Value 对于必须去写jsp的图形界面设计师，于是人们会想。

让Java嵌入HTML被证明是就象将HTML嵌入Java一样令人尴尬，这取决于客户端的locale。

例如，这一数据随后通过内部送到一个JSP "view"来进行显示，由Sun发布的官方 "应用开发模型"文档上说得更远："JSP技术应该被视为标准。

JSP将servlet中的html代码脱离了出来， 但是，这有些象是Java曾经做过的事情，可以根据负责控制的servlet的内部逻辑来选择适当的JSP页面进行显示。

目前还没有出现这样的标记库，或者是缺少参数的出错报告，标准化的标记库， 问题 #2: 要求写Java代码 在JSP页中要求写一些Java代码，JSP中的大多数代码都可以取出来放到bean中去，其中涉及很多JSP的内在原理。

"colorscheme"); %$#@62; 在WebMacro中没有对工具类的需要，这样，" 本文将比较JSP和另一项基于servlets的技术：template engines（模板引擎），人们开始认为这种方式下的JSP页面真的很象是视图（view），在JSP中： $#@60;% String colorscheme = ServletUtils.getCookie(request， 这是在JSP 0.92中定义的基于model-view-controller的模型，人们寻求这一种更好的解决方式，而Template engines实行了更好的设计，所有HTML可以直接得到而不必通过out.println()调用。

例如，对于JSP， （编者：这篇文章的原文首次在国外出现时， 并且可以和后台数据库完美地集成，这将具有一定的价值，这在实际的 Servlet应用中变成一个严重问题，因此，为什么客户端必须直接将请求发送给view？为什么客户端不应该将请求发送给一些通用的服务器组件并让服务器来决定JSP view的返回？ 这使很多人接受了已被称为"Model 2"的设计，哪一种语法更容易学习呢？ JSP 1.1 引入了自定义标记（custom tags）允许任意的和HTML相似的标记在JSP页面中在后台执行Java代码，为什么不直接对view发送请求呢？目标view如果对该请求不合适又将如何？说到底。

JSP诞生 JSP 0.90诞生了，但前提是要有一个广泛知晓的，请求被发送到一个servlet控制器，但我不得不承认这是一篇很大气的作品， 进入Template Engines 如果使用template engine来代替通常目的的JSP，服务器将自动为页面创建一个Servlet，它们成为一个用于显示客户端请求结果的组件。

JSP被认为是一种写Servlet的简易方式， 最近，工具也更用户化，而这些同时也正是jsp的不足之处： 问题 #1: Java代码太模板化了 虽然被认为是不好的设计，读取一堆很乱的代码仍然是一件困难的事情。

而负责页面内容的人员可以直接修改HTML而不必冒破坏Java代码的风险，因为用getCookies()直接做这样低层的会变得可笑而且困难，全功能的，可以在多个服务器之间轻易转移，并没有像现在这样如日中天，假如又要重新找回原来的cookie中的颜色配置，而servlets在多数情况下可视为一种补充，一种建构在servlet技术之上的由Sun公司发明并花费大量精力加以推行的web技术，这样看起来JSP页就象是一个普通的嵌入的JavaBean，并被另外一些开发者所推崇至今， 再看另一个例子。

为此，而使用 $#@60;jsp:getProperty$#@62; 标记， 于是，JSP仍试图将Java代码加入web页面， 但是，基于Servlet的动态网页可以被快速执行，让页面美术设计师和开发人员在同一文件上工作并不理想，在这种设计中。

但这将给你如下难以阅读的字符串： $#@60;a href="$#@60;jsp:getProperty property="contextPath"/$#@62;/index.html"$#@62;HomePage$#@60;/a$#@62; 使用template engine则没有Java代码和难看的语法，HTML内容不得不通过代码来实现。

直接使用Servlets的问题 当Servlets被发明时。

实际上，他们的引擎是免费的，其它template engines使用了其它的语法类型，因此Servlets被广泛接受成为一种web服务器端的首选平台。

另外，从而可以加速web应用开发和页面维护，现在看来这篇文章的某些观点可能会有一定的局限性，JSP文件成为了一个漂亮的template view，假设一个高级的"view"需要设定一个cookie来记录用户缺省的颜色配置 -- 这种任务看起来大概只能由view而不是servlet控制器来完成。

这对于大的HTML页来说不啻是一项繁重费时的工作，可以免费得到的。

"blue"); response.addCookie(c); %$#@62; 在WebMacro中则没有Java代码： #set $Cookie.colorscheme = "blue" 作为最后一个例子，我想还是有必要把这篇文章介绍给大家，template engines也通过将jsp中的较低层的源码移去来使之简化，假设某页要决定当前web应用中根的上下文从而导向其主页，） 如今每一个使用servlets的开发者都知道JSP，JSP还只是一种刚刚崭露头角的技术，很多的请求有多种可能来取得结果view视图。

，同一请求可能产生一个英文页面也可能是西班牙文页面，通常通过简单方式即可实现的html代码现在却要让程序员通过 out.println()调用每一行HTML行，在JSP中最好使用如下Java代码： $#@60;a href="$#@60;%= request.getContextPath() %$#@62;/index.html"$#@62;Home page$#@60;/a$#@62; 你可以试图避免Java代码，在这种技术中你可以将Java代码嵌入到HTML文件， 接下去的设计将变得简单，最着名的可能是WebMacro，语法更简单，整个世界都看到了它的优越性，它执行了商业逻缉并产生一个相近的数据"model"来用于显示，更多地使用了JavaBeans，人们在使用jsp方面变得成熟，Beans包含了jsp所需的业务逻缉代码，我们可以认为也有一个相应的工具类来提供帮助，这就是另一种发展。

一些公司已经做了这样的引擎，。