这使很多人接受了已被称为"Model 2"的设计, 这是在JSP 0.92中定义的基于model-view-controller的模型。在这种设计中，请求被发送到一个servlet控制器，它执行了商业逻缉并产生一个相近的数据"model"来用于显示。这一数据随后通过内部送到一个JSP "view"来进行显示，这样看起来JSP页就象是一个普通的嵌入的JavaBean。可以根据负责控制的servlet的内部逻辑来选择适当的JSP页面进行显示。这样，JSP文件成为了一个漂亮的template view。这就是另一种发展，并被另外一些开发者所推崇至今。
进入Template Engines
如果使用template engine来代替通常目的的JSP, 接下去的设计将变得简单，语法更简单，出错信息更易读，工具也更用户化。一些公司已经做了这样的引擎，最著名的可能是WebMacro，他们的引擎是免费的。
开发者应该明了，选定一个template engine来取代JSP提供了以下一些技术优势，而这些同时也正是jsp的不足之处：
问题 #1: Java代码太模板化了
虽然被认为是不好的设计，JSP仍试图将Java代码加入web页面。这有些象是Java曾经做过的事情，即对C++的简化修改，template engines也通过将jsp中的较低层的源码移去来使之简化。而Template engines实行了更好的设计。
问题 #2: 要求写Java代码
在JSP页中要求写一些Java代码。例如，假设某页要决定当前web应用中根的上下文从而导向其主页，在JSP中最好使用如下Java代码：
/index.html">Home page
你可以试图避免Java代码，而使用
/index.html">HomePage
使用template engine则没有Java代码和难看的语法。这里是同样要求下在WebMacro中的写法：
Home page
在WebMacro中, ContextPath 作为 $Request变量的一个属性，使用类似Perl的语法。其它template engines使用了其它的语法类型。
再看另一个例子，假设一个高级的"view"需要设定一个cookie来记录用户缺省的颜色配置 -- 这种任务看起来大概只能由view而不是servlet控制器来完成。在JSP中要有这样的Java代码：
<% Cookie c = new Cookie("colorscheme", "blue"); response.addCookie(c); %>
在WebMacro中则没有Java代码：
#set $Cookie.colorscheme = "blue"
作为最后一个例子，假如又要重新找回原来的cookie中的颜色配置。对于JSP，我们可以认为也有一个相应的工具类来提供帮助，因为用getCookies()直接做这样低层的会变得可笑而且困难。在JSP中：
<% String colorscheme = ServletUtils.getCookie(request, "colorscheme"); %>
在WebMacro中没有对工具类的需要，通常是：
$Cookie.colorscheme.Value
