公司使用现成的HTML 然后在加载完页面之后使用js来加载数据，这带来了很多潜在威胁。所以今天来看看其他框架是怎么做的。作为参考的框架是playframework。
在Play Framework中，每个请求最终会调用一个开发者定义的action函数。开发者在这个函数中对请求进行处理。也就是控制层的逻辑。在action函数中，开发者可能需要根据请求使用模型层的数据，并将数据传送给模板，也就是视图层。之后交由框架处理，将数据加载到模板中，并完成最终输出。一个action函数大概是这样：
public class Application extends Controller {
public static void stockCommit(
String barCode,
String name,
Long cost,
Long price,
Integer stock){
if(!(barCode != null
&& name != null
&& cost != null
&& price != null
&& stock != null)){
String message = "输入有误";
render(message);
}
Product p = new Product();
p.barCode = barCode;
p.name = name;
p.cost = cost;
p.price = price;
p.stock = stock;
p.save();
render(p);
}
这里的Application 类继承了Controller，定义了stockCommit方法，处理提交库存的请求。一般的控制层的任务便是如此，处理数据，并最终显示页面。
页面由模板文件而来，模板文件中使用了占位符并可能运行一些Groovy代码。模板可能已经编译过，变成单纯的Groovy代码。调用render() 之后，这个模板文件会被执行（使用Groovy解释器）并返回最终的HTML代码。调用层次如下：
Controller.render
->Controller.renderTemplate
->Controller.template //找出actin对应的template名字
->TemplateLoader.load //根据找出的template名字加载template并编译（如果还未编译的话）
->throw new RenderTemplate(Template template, Map<String, Object> args) extends Result //将找出的template模板交给RenderTemplate
->Template.render( Map<String, Object> args ) //RenderTemplate调用传入的template中的render，得到最终的输出
->Template.internalRender( new HashMap<String, Object>(args) )
-->GroovyTemplate.internalRender
这里关键一步便是Template.internalRender( new HashMap<String, Object>(args) )。 这个函数里面，准备了Groovy运行环境，并最终将模板文件执行（此时的模板文件已经被编译成Groovy代码）。最终执行结果是一个String，便是最终要返回给用户的页面内容。此后这个String由框架输出给服务器，服务器将内容返回给浏览器。Play Framework的框架核心部分很有意思，网上有相关描述，这里不说。
可以看到，Play Framework的页面是在一个请求到来之后才生成的，在生成之前相关数据已经准备好，并嵌入到页面中。这其实是大部分框架的作法。这么做的特点是：
1. 业务逻辑在后台执行。
2. 每次都需要运行模板文件并生成最终的字符串。
相比之下，公司的作法是：
1. 在请求来的时候找出对应页面（HTML），并返回给用户.
2. 页面包含JS代码，在页面加载完成的时候立即执行，调用后台Java代码，收集数据并填补到页面上。
这么做的特点是：
1. 页面加载分为两步骤，先加载整个页面再加载数据。
2. 所有页面会在服务器启动的时候生成，被调用的时候只需要读取并输出即可。
在有些时候，有些控件会根据数据的不同而有不同的行为，而这些行为都是由JS控制的，这样一来用户很容易就可以通过运行JS来改变这些控件的行为，带来了很大的安全隐患。由于页面是原先就有的，所以必须提供“最大级别”的控件集合，然后再在客户端进行限制。这实际上相当于没法控制（客户端可以自己编写JS代码并在当前页面上执行）。
而由后台动态生成页面的作法就不同了。先有数据再有页面，页面的最终效果由数据决定，传送到客户端的都是“恰当级别”的控件集合。这对于ERP 产品来说很重要。
另外，考虑到速度与效率方面。Play Framework可以预编译好所有的模板，需要的时候将模板脚本运行，其实也就是将其包含的字符串填上占位符并全部输出即可，没有复杂逻辑。而直接输出HTML 的作法，其实也是读取文件并将其输入到服务器的输出流上。更何况在加载完页面之后还需要第二次通信将数据填补到页面上。
明天有机会的话去问问开发这个框架的组，看他们是怎么说的。
