基于 Java 的网站开发，很多人都采用 JSP 作为前端网页制作的技术，尤其在是国内。这种技术通常有一些问题，我试想一下我们属羊的今年多大是怎样开发网站的，通常有几种方法：
1：功能确定后，由美工设计网页的UI（界面）部分，然后由程序员在其上加入代码显示逻辑（比如循环，判断显示数据结果）。也就是通常的 jsp 页面制作，当然这部分可以由美工完成模板，然后由 jsp 工程师再继续以它为原型创建相应的 jsp 页面。
2：功能确定后，由美工设计网页的UI（界面）部分，然后由网页制作人员在其上加入代码显示逻辑（比如循环，判断显示数据结果），在这一步的 jsp 页面制作中，网页制作人员（通常只懂得 javascript 和 html ）在工程师的指导下学会如何嵌入 jsp taglib 标记，然后以美工的模板为原型制作 jsp 网页。
显然后面一种方式要比前面一种方式分工明确，然后在很多小公司，或者项目很急的情况下，jsp 网页制作和后台程序开发都是同一个人。这样无疑加大了程序员的负担。 后一种情况虽然比前面的好，但是它有两个缺点： 一：网页制作人员必须学会如何使用 jsp taglib 的使用，这无疑加大了网页制作人员的负担。二：如果页面因为客户的要求从新设计，那么无论那种情况网页制作人员都要从新将显示逻辑从新嵌入 jsp 网页。
在这方面， jsp 做的并不好，虽然从性能角度和 taglib 的使用上来说，它比 php 和 asp 要强很多， 但是它在设计上很类似 php 这种服务器页面语言，也就是在页面中嵌入脚本语言的技术，虽然它比传统的基于 CGI 的脚本语言的开发模式速度快，但是它将后台程序逻辑与页面显示混淆了，所以从这个角度来说, 它是一种不太良好的设计。想想看，你看到的众多 php 程序是怎么样子的吧，在一堆 .php 文件中，你已经分不清楚那些是后台程序，那些只是用来显示页面的程序。
现在更多的网站制作采用一种 MVC 模式，也就是将网站制作工作分工，分别为M(Model, 模型)，V（View 视图），C(Controller 控制器).
M(Model, 模型）也就是后台的事务逻辑，真正处理事务的代码，商业逻辑等等。他们是整个网站最重要的工作部分，通常这部分代码相对来说比较稳定，不经常变动，就是有所变动也不会对前端的页面有什么影响。
这种职责的分工到底有什么好处呢，它简化了软件开发过程中所有相关人员的工作， 使得不同的部分的修改通常不会影响的其他部分的工作，比如，我修改了后台某些程序的算法，并不影响前台的页面显示，前台页面修改不影响后台程序的开发。这种分工合作比起 jsp 混淆代码逻辑和显示层的做法要好的多。
所以越来越多的国外程序员在不断提出替代 jsp 的方案，在众多方案中， 一种基于 java 模板引擎的技术脱颖而出，最为著名的是 Velocity 和 Webmacro 两种模板技术。
模板引擎的设计思想最早是有 webmacro 提出的， 后来应用在一个著名的搜索引擎上， 这种思想渐渐被 Apache 开发小组所采用，并作为一个子项目被提出来，这就是现在的 Velocity。模板引擎与MVC中视图这一部分的关系更为密切。它是经常作为一种 jsp 的替代技术出现在国外的一些论坛上的。但是 Velocity 可以应用在任何需要格式化数据显示的 java 程序中。
Velocity 是一种基于 java 的模板引擎，它允许任何人使用简单而强大的模板语言来引用定义在 java 代码中的对象
Velocity 的强大之处在于它严格的区分程序开能的职责划分。 它模板可能访问的对象（也就是后台程序允许它得到的对象）来实现这一点。这意味着，网页设计人员可以只把精力放在数据的显示部分（View 视图）而程序员则只要关注如何写好程序的控制层（Controller,控制器）和商业逻辑和数据管理（模型 Model）, 这就是 MVC 开发模式。MVC 现在已经是广泛接受的一种开发模式，它简化了开发和日益复杂的应用和工作。
不过 Velocity 用的最多的还是在基于 Java servlet 的网页程序中作生成网页的引擎，以替代 JSP 等技术。 除了比较容易使用外， 它提供了强大的模板语言以显示和操作数据，但是不是生成数据，这点很重要， 因为这个工作应该是程序逻辑的部分。 Velocity 非常适合在 J2EE (Java 2 Platform, Enterprise Edition) 的网站开发中充当替代 jsp 做输出页面的技术工作，虽然 JSP 包含在 j2ee 的规范中，其实 j2ee 本身并不需要 jsp .
似乎所有语言教学的开头都是采用 HelloWorld 来作为第一个程序的示例。这里也不例外。
为了运行顺利，请从 Velocity 的网站上下载 Velocity 的运行包，将其中的 Velocity Jar 包的径放在系统的 Classpath 中，这样就可以编译和运行以上的程序了。
这个程序很简单，但是它能让你清楚的了解 Velocity 的基本工作原理。程序中其他部分基本上很固定，最主要的部分在以下代码
context.put(site, 其他代码比较固定，但是也非常重要，但是对于每个应用来说写法都很相同：
System.out.println( writer.toString() ); 记住，这在将来的 servlet 应用中会有所区别，因为网页输出并不和命令行输出相同，如果用于网页输出，将并不通过 System.out 输出。这会在以后的教程中给大家解释的。
Velocity 解决了如何在 Servlet 和 网页之间传递数据的问题，当然这种传输数据的机制是在 MVC 模式上进行的，也就是View 和 Modle , Controller 之间相互工作，一方的修改不影响其他方变动，他们之间是通过变量（Context）来实现的，当然双方网页制作一方和后台程序一方要相互约定好对所传递变量的命名约定，比如上个程序例子中的 site, name 变量，它们在网页上就是 $name ,$site 。 这样只要双方约定好了变量名字，那么双方就可以工作了。 无论页面如何变化，只要变量名不变，那么后台程序就无需改动，前台网页也可以任意由网页制作人员修改。这就是 Velocity 的工作原理。
你会发现简单变量名通常无法满足网页制作显示数据的需要，比如我们经常会循环显示一些数据集，或者是根据一些数据的值来决定如何显示下一步的数据， Velocity 同样提供了循环，判断的简单语法以满足网页制作的需要。Velocity 提供了一个简单的模板语言以供前端网页制作人员使用，这个模板语言足够简单（大部分懂得 javascript 的人就可以很快掌握，其实它比 javascript 要简单的多），当然这种简单是刻意的，因为它不需要它什么都能做， View 层其实不应该包含更多的逻辑，Velocity 的简单模板语法可以满足你所有对页面显示逻辑的需要，这通常已经足够了，这里不会发生象 jsp 那样因为一个无限循环语句而毁掉系统的情况，jsp 能做很多事情，Sun 在制定 Jsp 1.0 标准的时候，没有及时的限定程序员在 jsp 插入代码逻辑，使得早期的jsp 代码更象是 php 代码，它虽然强大，但是对显示层逻辑来说，并不必要，而且会使 MVC 三层的逻辑结构发生混淆。