公司使用現(xiàn)成的HTML 然后在加載完頁面之后使用js來加載數(shù)據(jù)，這帶來了很多潛在威脅。所以今天來看看其他框架是怎么做的。作為參考的框架是playframework。
在Play Framework中，每個(gè)請(qǐng)求最終會(huì)調(diào)用一個(gè)開發(fā)者定義的action函數(shù)。開發(fā)者在這個(gè)函數(shù)中對(duì)請(qǐng)求進(jìn)行處理。也就是控制層的邏輯。在action函數(shù)中，開發(fā)者可能需要根據(jù)請(qǐng)求使用模型層的數(shù)據(jù)，并將數(shù)據(jù)傳送給模板，也就是視圖層。之后交由框架處理，將數(shù)據(jù)加載到模板中，并完成最終輸出。一個(gè)action函數(shù)大概是這樣：
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方法，處理提交庫存的請(qǐng)求。一般的控制層的任務(wù)便是如此，處理數(shù)據(jù)，并最終顯示頁面。
頁面由模板文件而來，模板文件中使用了占位符并可能運(yùn)行一些Groovy代碼。模板可能已經(jīng)編譯過，變成單純的Groovy代碼。調(diào)用render() 之后，這個(gè)模板文件會(huì)被執(zhí)行（使用Groovy解釋器）并返回最終的HTML代碼。調(diào)用層次如下：
Controller.render
->Controller.renderTemplate
->Controller.template //找出actin對(duì)應(yīng)的template名字
->TemplateLoader.load //根據(jù)找出的template名字加載template并編譯（如果還未編譯的話）
->throw new RenderTemplate(Template template, Map<String, Object> args) extends Result //將找出的template模板交給RenderTemplate
->Template.render( Map<String, Object> args ) //RenderTemplate調(diào)用傳入的template中的render，得到最終的輸出
->Template.internalRender( new HashMap<String, Object>(args) )
-->GroovyTemplate.internalRender
這里關(guān)鍵一步便是Template.internalRender( new HashMap<String, Object>(args) )。 這個(gè)函數(shù)里面，準(zhǔn)備了Groovy運(yùn)行環(huán)境，并最終將模板文件執(zhí)行（此時(shí)的模板文件已經(jīng)被編譯成Groovy代碼）。最終執(zhí)行結(jié)果是一個(gè)String，便是最終要返回給用戶的頁面內(nèi)容。此后這個(gè)String由框架輸出給服務(wù)器，服務(wù)器將內(nèi)容返回給瀏覽器。Play Framework的框架核心部分很有意思，網(wǎng)上有相關(guān)描述，這里不說。
可以看到，Play Framework的頁面是在一個(gè)請(qǐng)求到來之后才生成的，在生成之前相關(guān)數(shù)據(jù)已經(jīng)準(zhǔn)備好，并嵌入到頁面中。這其實(shí)是大部分框架的作法。這么做的特點(diǎn)是：
1. 業(yè)務(wù)邏輯在后臺(tái)執(zhí)行。
2. 每次都需要運(yùn)行模板文件并生成最終的字符串。
相比之下，公司的作法是：
1. 在請(qǐng)求來的時(shí)候找出對(duì)應(yīng)頁面（HTML），并返回給用戶.
2. 頁面包含JS代碼，在頁面加載完成的時(shí)候立即執(zhí)行，調(diào)用后臺(tái)Java代碼，收集數(shù)據(jù)并填補(bǔ)到頁面上。
這么做的特點(diǎn)是：
1. 頁面加載分為兩步驟，先加載整個(gè)頁面再加載數(shù)據(jù)。
2. 所有頁面會(huì)在服務(wù)器啟動(dòng)的時(shí)候生成，被調(diào)用的時(shí)候只需要讀取并輸出即可。
在有些時(shí)候，有些控件會(huì)根據(jù)數(shù)據(jù)的不同而有不同的行為，而這些行為都是由JS控制的，這樣一來用戶很容易就可以通過運(yùn)行JS來改變這些控件的行為，帶來了很大的安全隱患。由于頁面是原先就有的，所以必須提供“最大級(jí)別”的控件集合，然后再在客戶端進(jìn)行限制。這實(shí)際上相當(dāng)于沒法控制（客戶端可以自己編寫JS代碼并在當(dāng)前頁面上執(zhí)行）。
而由后臺(tái)動(dòng)態(tài)生成頁面的作法就不同了。先有數(shù)據(jù)再有頁面，頁面的最終效果由數(shù)據(jù)決定，傳送到客戶端的都是“恰當(dāng)級(jí)別”的控件集合。這對(duì)于ERP 產(chǎn)品來說很重要。
另外，考慮到速度與效率方面。Play Framework可以預(yù)編譯好所有的模板，需要的時(shí)候?qū)⒛０迥_本運(yùn)行，其實(shí)也就是將其包含的字符串填上占位符并全部輸出即可，沒有復(fù)雜邏輯。而直接輸出HTML 的作法，其實(shí)也是讀取文件并將其輸入到服務(wù)器的輸出流上。更何況在加載完頁面之后還需要第二次通信將數(shù)據(jù)填補(bǔ)到頁面上。
明天有機(jī)會(huì)的話去問問開發(fā)這個(gè)框架的組，看他們是怎么說的。
