微人資訊: June 2008

目前程式與頁面結合的作法
1. 由美工人員先行編制頁面內容, 再行嵌入CGI程式中
2. XML + XSLT
3. 在CGI程式中將load進來的html檔案, 以正規表示法予以置換

採用以上方法的優缺點
1 由美工人員先行編制頁面內容, 再行嵌入CGI程式中
1.1 頁面與程式交雜在一起, 日後不易維護
1.2 程式人員需自行切割已完成的頁面, 再嵌入程式碼
1.3 日後頁面欲增加新功能或顯示欄位, 則需返回美工人員處做異動
1.4 遇相同功能的頁面無法做成模組化, 讓頁面可重複使用
1.5 實例：電腦教室系統、卡務系統
2 XML + XSLT
2.1 頁面與程式可以完全分離, 使得開發人員可各自維護
2.2 可將相同功能的頁面做成模組化, 讓頁面可重複使用
2.3 對XML異動Tag內容時, 無法透過簡易的方式告知頁面維護人員Tag資料內容已異動, 需透過XML Schema才可得知
2.4 實例：清算系統
3 在CGI程式中將load進來的html檔案, 以正規表示法予以置換
3.1 頁面與程式可以完全分離, 使得開發人員可各自維護
3.2 樣版與程式中對於取代用的變數名稱需一致, 才可順利被置換
3.3 異動(新增、修改、刪除)變數名稱, 需另行告知美工維護人員變數異動內容
3.4 較不易把相同功能的頁面做成模組化, 缺少頁面重用的理念
3.5 實例：清算系統報表處理

以上的方式各有優缺點但我畢竟希望程式與頁面可以完全分離, 版面的設計交給專業的美工人員, 而美工人員只需以html為基準(畢竟美工人員大多使用Dreamweaver或Frontpage之類的來設計版面), 不需讓美工人員去學習程式語言(只需透過雙方已制定的協定文件), 而達到完全分工的效能, 這也就為什麼目前樣版這麼熱門的原因了

為什麼要使用樣版 ??

1. 外觀的一致性 (Consistency of Appearance)
It doesn't take a genius to see that making one navigation bar template and using it in all of your pages is easier to manage than hard-coding it every where. If you build your whole site like this, it's much easier to make site-wide changes in the look and feel.

樣版可使得有包含大量編碼的頁面在任何地方都可輕易的被維護, 而且對於站台在外觀及感覺上有更寛廣的變化

2. 重用 (Reusability)
Along the same lines, building a set of commonly used components makes it easier to create new pages

在於新建立的新頁面中可重覆去使用一般性的樣版組合, 達到重覆使用的效果

3. 更好隔離變化 (Better lsolation from Changes)
Which one changes more often, the logic of your application or the HTML used to display it? It actually doesn't matter which you answered, as long as it's one of them. Templates can be a great abstraction layer between the application logic and the display logic, allowing one to be updated without touching the other.

不論是邏輯性的程式碼或顯示用的html碼任其一的變化, 都可被單獨的維護, 而樣版可達到這樣的功能

4. 分工 (Division of Labor)
Separating your Perl code from your HTML means that when your marketing department decides everything should be green instead of blue, you don't have to lift a finger. Just send them to the HTML coder down the hall. It's a beautiful thing, getting out of the HTML business.

Even if the same people in your organization write the Perl code and the HTML, you at last have the opportunity for more people to be working on the project in parallel

可讓程式設計人員與版面美工設計人員的工作可各自分離, 以達到分工的效益

何謂Web樣版系統
1. Web Template System : http://en.wikipedia.org/wiki/Web_template_system A web template system is comprised of:
1. A Template engine: the primary processing element of the system;
(樣版引擎: 樣版系統最主要的處理元素)
2. Content resource: any of various kinds of input data streams, such as from a relational database, XML files, LDAP directory, and other kinds of local or networked data;
(資料內容來源: 各式各樣的輸入資料串列, 如: 來自於資料庫(DB)的資料, XML檔案, LDAP Server, 或其它本地端或網路上的資料)
3. Template resource: web templates specified according to a Template language;
(樣版來源: 依照樣版語言制定web樣版)

2. Web Template System Image

Web Template System

何謂Template Engin
1. Template engins: http://en.wikipedia.org/wiki/Template_engine_%28web%29
A (web) template engine is software that is designed to process web templates and content information to produce output web documents. It runs in the context of a template system.
(樣版引擎被設計為用於處理web樣版及內容資訊而產生輸出web文件的一項軟體, 它是在樣版
系統中被運作)
Template Engin

2. Template Engins型態規格
Template engine is ordinarily included as a part of a web template system or application framework, and may be used also as preprocessor, filter, or template processor. Currently, template processing software is most frequently used in the context of development for the web.

XSLT is a template processing model designed by W3C. It is designed primarily for
transformations on XML data (into web documents or other output).

Programming languages such as Perl, Ruby, C, and Java support template processing
either natively, or through add-on libraries and modules. JavaServer Pages (JSP), PHP,
and Active Server Pages (ASP with VBScript, JScript or other languages) are examples,
themselves, of web template engines.

樣版引擎通常是被包含在web template system或appliaction framework的一部份, 它有
可能被當作一個預先處理器, 過濾器, 或樣版處理器, 現在, 樣版處理軟體最常被使用在開
發Web的背景所使用

XSLT被W3C設計為樣版處理模式, 它最主要被設計於用來轉換XML資料

程式語言像Perl, Ruby, C及Java都支援樣版的處理, 並且是自然而然的憑藉著附加的Libraries或Modules來做開發, Java Server Pages(JSP), PHP及Active Server Page(ASP與VBScript, Jscript或其它語言), 它們自己本身就是很好的例子(Web樣版引擎的成員)

3. Template Engins基本特點
Template engines typically include features common to most high-level programming languages, with an emphasis on features for processing plain text.
Such features include:
variables and functions
text replacement
file inclusion (or transclusion)
conditional evaluation and loops
樣版引擎對於大多高階程式語言包含一般性的持點, 文字的處理乃是其強調的特點
其它特點包含
1. 變數及功能
2. 文字的置換
3. 檔案的包含或轉換
4. 條件式的計算及資料循環

以Perl為base來看Template System
Pipeline & callback型式比較: http://perl.apache.org/docs/tutorials/tmpl/comparison/comparison.html

以下是該文章部份翻譯摘要
l 樣版處理模式
Although some try to be flexible about it, most templating systems expect you to use some variation of the two basic execution models, which I will refer to as "pipeline" and "callback." In the callback style, you let the template take over and it has the application's control flow coded into it. It uses callbacks to modules or snippets of in-line Perl code to retrieve data for display or perform actions like user authentication. Some popular examples of systems using this model include Mason, Embperl, and Apache::ASP.
The pipeline style does all the work up front in a standard CGI or mod_perl handler, then decides which template to run and passes some data to it. The template has no control flow logic in it, just presentation logic, e.g. show this graphic if this item is on sale. Popular systems supporting this approach include HTML::Template and Template Toolkit.
The callback model works very well for publishing-oriented sites where the pages are essentially mix and match sets of articles and lists. Ideally, a site can be broken down into visual "components" or pieces of pages which are general enough for an HTML coder to re-combine them into entirely new kinds of pages without any help from a programmer.
The callback model can get a bit hairy when you have to code logic that can result in totally different content being returned. For example, if you have a system that processes some form input and takes the user to different pages depending on the data submitted. In these situations, it's easy to end up coding a spaghetti of includes and redirects, or putting what are really multiple pages in the same file.
On the other hand, a callback approach can result in fewer files (if the Perl code is in the HTML file), and feels easier and more intuitive to many developers. It's a simple step from static files to static files with a few in-line snippets of code in them. This is part of why PHP is so popular with new developers.
The pipeline model is more like a traditional model-view-controller design. Working this way can provide additional performance tuning opportunities over an approach where you don't know what data will be needed at the beginning of the request. You can aggregate database queries, make smarter choices about caching, etc. It can also promote a cleaner separation of application logic and presentation. However, this approach takes longer to get started with since it's a bigger conceptual hurdle and always involves at least two files: one for the Perl code and one for the template.
Keep in mind, many systems offer significant flexibility for customizing their execution models. For example, Mason users could write separate components for application logic and display, letting the logic components choose which display component to run after fetching their data. This allows it to be used in a pipeline style. A Template Toolkit application could be written to use a simple generic handler (like the Apache::Template module included in the distribution) with all the application logic placed in the template using object calls or in-line Perl. This would be using it in a callback style.
HTML::Template is fairly rigid about insisting on a pipeline approach. It doesn't provide methods for calling back into Perl code during the HTML formatting stage; you have to do the work before running the template. The author of the module consider this a feature since it prevents developers from cheating on the separation of application code and presentation.
1 樣版系統基本上可分為2種模式, pipeline(管道) 及 callback (回調)
2 Callback (管道) 模式
2.1 樣版可自行接管應用控制流程碼在樣版中
2.2 Callback模式的樣版系統代碼如: HTML::Mason, HTML::Embperl, Apache::ASP
2.3 Callback模式對於以出版為方向的站台來說是最好的, 可將該站台交相混雜的物品及目錄, 打散成多個虛擬的 “components” 或者是一個個頁面, 讓html編輯人員不需由程式人員那裡得到援助, 即可將不同的頁面重新整合成多種組合新頁面
2.4 Callback模式在處理所編輯的邏輯編碼於完全不同內容被回傳結果時是會變得令人感到棘手的, 舉例來說, 假設有個系統乃用於處理一些表格輸入或者是帶著使用者進入到其它不同的頁面時, 在這個種狀況下, Callback模式是很容易終止如管線般複雜的includes及redirects的編碼
2.5 Callback模式可產生較少的檔案(如: perl的程式碼是包含在html文件中), 而對於開發者來說更容易直覺去開發程式, 只需包含些許的程式區塊在樣版裡, 這也就是為什麼對一個新的開發者來說PHP那麼愛歡迎的原因

Perl Compile

Result Dispaly

Template(perl code) Callback

Apache::ASP

3 Pipeline (回調) 模式
3.1 在CGI或mod_perl handler 作業最前面, pipeline模式含括了所有的工作, 例如: 決定哪一個樣版要被執行及傳遞哪些資料…等等
3.2 樣版無邏輯性的控制流程, 只需提出邏輯即可
3.3 pipeline模式的樣版系統代碼如: HTML::Template, Template Toolkit
3.4 Pipeline模式就像傳統的 model-view-controller(MVC)設計, 採用這個模式將可提供額外的效能調校機會, 可去統合資料庫的需求, 採用更聰明的選擇如caching…等等, Pipeline模式也可提昇為一個用於分離應用邏輯及外觀的清潔員, 而這模式在於一開始也花費較長時間, 因此它是一個大型的困難障礙以及它永遠牽絆著至少2個檔案: 一個是perl的程式碼, 一個是樣版
3.5 MVC相關資訊連結可參考http://zh.wikipedia.org/wiki/MVC
3.6
CGI + Template

Result DispalyHTML::Template是一個完全綁定在pipeline模式的, 在HTML在格式化階段期間, HTML::Template對於回呼(calling back)到perl程式碼沒有提供任何方法, 你必需在執行樣版之前就需完成工作
HTML::Template

Perl Compile

4 記住, 很多系統都會為他們實作模型而提供有效的靈活性, 舉例來說, Mason的使用者自獨編寫邏輯component及外觀component, 在取得資料之後, 讓邏輯component可自行選取外觀component予以執行, 而這個型式也可套用在pipeline模式, Template Toolkit應用可寫成簡易使用處理器(就像在分散式架構下包含Apache::Template模組)一般, 及所有的應用邏輯放置在樣版中使用物件呼叫(object calls)或perl線型區塊(in-line perl)
l In-line perl (內含perl程式碼區塊) & mini-language & DOM Tree
Some systems use in-line Perl statements. They may provide some extra semantics, like Embperl's operators for specifying whether the code's output should be displayed or Mason's <%init> sections for specifying when the code gets run, but at the end of the day your templates are written in Perl.
Other systems provide a specialized mini-language instead of (or in addition to) in-line Perl. These will typically have just enough syntax to handle variable substitution, conditionals, and looping. HTML::Template and Template Toolkit are popular systems using this approach.
Here's how a typical discussion of the merits of these approaches might go:
IN-LINE: Mini-languages are stupid. I already know Perl and it's easy enough. Why would you want to use something different?
MINI-LANG: Because my HTML coder doesn't know Perl, and this is easier for him.
IN-LINE: Maybe he should learn some Perl. He'd get paid more.
MINI-LANG: Whatever. You just want to use in-line Perl so you can handle change requests by putting little hacks in the template instead of changing your modules. That's sloppy coding.
IN-LINE: That's efficient coding. I can knock out data editing screens in half the time it takes you, and then I can go back through, putting all the in-line code into modules and just have the templates call them.
MINI-LANG: You could, but you won't.
IN-LINE: Is it chilly up there in that ivory tower?
MINI-LANG: Go write some VBScript, weenie.
etc.
Most people pick a side in this war and stay there. If you are one of the few who hasn't fully decided yet, you should take a moment to think about who will be building and maintaining your templates, what skills those people have, and what will allow them to work most efficiently.
Here's an example of a simple chunk of template using first an in-line style (Apache::ASP in this case) and then a mini-language style (Template Toolkit). This code fetches an object and displays some properties of it. The data structures used are identical in both examples. First Apache::ASP:
Apache::ASP (in-line perl)
<% my $product = Product->load('sku' => 'bar1234'); %>
<% if ($product->isbn) { %>
It's a book!
<% } else { %>
It's NOT a book!
<% } %>
<% foreach my $item (@{$product->related}) { %>
You might also enjoy <% $item->name %>.
<% } %>
Template Toolkit (mini-language)
[% USE product(sku=bar1234) %]

[% IF product.isbn %]
It's a book!
[% ELSE %]
It's NOT a book!
[% END %]
[% FOREACH item = product.related %]
You might also enjoy [% item.name %].
[% END %]
There is a third approach, based on parsing an HTML document into a DOM tree and then manipulating the contents of the nodes. The only module using this approach is HTML_Tree. The idea is similar to using a mini-language, but it doesn't require any non-standard HTML tags and it doesn't embed any logic about loops or conditionals in the template itself. This is nice because it means your templates are valid HTML documents that can be viewed in a browser and worked with in most standard HTML tools. It also means people working with the templates can put placeholder data in them for testing and it will simply be replaced when the template is used. This preview ability only breaks down when you need an if/else type construct in the template. In that situation, both the "if" and "else" chunks of HTML would show up when previewing.
1 in-line perl模式 (內含perl語法區塊)
1.1 Perl程式碼可完全整合在HTML文件中
1.2 一般來說in-line perl模式都會採用callback模式來處理, 但也有採用pipeline模式的
1.3 運用in-line perl模式, 建議先行安裝mod_perl
1.4 有特殊的Token去包含perl的程式碼
1.4.1 HTML::Mason採用 <%...........%> 、</%> 、 <%...........> 區塊標籤規格
1.4.2 HTML::Embperl 採用 [$ ……… $] 區塊標籤規格, [ ] 中括號內的$符號可依設定而變更如, [+ ……… +] 、 [* ……… *] 、 [- ……… -], …等等
1.4.3 Apache::ASP 採用<%...........%>
2 Mini-language模式
2.1 HTML::Template & Template Toolkit
2.2 樣版與程式可完全分散在不同的頁面中, 讓不同維護人員各自異動其相關檔案內容
2.3 需採用特殊語法並應用在樣版中
2.4 樣版與程式之間的變數命名規則需先行規劃
3 不管選用in-line perl模式或mini-language模式, 值得我們花時間去思考的問題是
3.1 有誰可以去維護或建立樣版
3.2 這些維護或建立樣版的人有什麼樣的技術
3.3 認可他們去進行什麼是最有效益的
4 由範例去得知in-line perl模式或mini-language模式的程式編輯方式
4.1 範例1: 以Apache::ASP為例
4.2 範例2: 以Template Toolkit為例
5 DOM Tree模式
5.1 解析一份html文件成為DOM Tree及運作各節點的內容
5.2 唯一使用該模式的模組為HTML_Tree
5.3 該模式類似於mini-language模式, 但它不需要任何非標準化的html標籤, 也不用嵌入任何如loop, conditional在它的樣版中
5.4 採該模式樣版在流覽器中可被檢視及在大多數的html編輯器可被運作
l Parsers & Caching (解析器與快取緩存技術)
The parsers for these templating systems are implemented in one of three ways: they parse the template every time ("repeated parse"), they parse it and cache the resulting parse tree ("cached parse tree"), or they parse it, convert it to Perl code, and compile it ("compiled").
Systems that compile templates to Perl take advantage of Perl's powerful runtime code evaluation capabilities. They examine the template, generate a chunk of Perl code from it, and eval the generated code. After that, subsequent requests for the template can be handled by running the compiled bytecode in memory. The complexity of the parsing and code generation steps varies based on the number of bells and whistles the system provides beyond straight in-line Perl statements.
Compiling to Perl and then to Perl bytecode is slow on the first hit but provides excellent performance once the template has been compiled, since the template becomes a Perl subroutine call. This is the same approach used by systems like JSP (Java ServerPages). It is most effective in environments with a long-running Perl interpreter, like mod_perl.
HTML::Template, HTML_Tree, and the 2.0 beta release of Embperl all use a cached parse tree approach. They parse templates into their respective internal data structures and then keep the parsed structure for each processed template in memory. This is similar to the compiled Perl approach in terms of performance and memory requirements, but does not actually involve Perl code generation and thus doesn't require an eval step. Which way is faster, caching the parse tree or compiling? It's hard to objectively measure, but anecdotal evidence seems to support compilation. Template Toolkit used a cached parse tree approach for version 1, but switched to a compilation approach for version 2 after tests showed it to offer a significant speed increase. However, as will be discussed later, either approach is more than fast enough.
In contrast to this, a repeated parse approach may sound very slow. However, it can be pretty fast if the tokens being parsed for are simple enough. Systems using this approach generally use very simple tokens, which allows them to use fast and simple parsers.
Why would you ever use a system with this approach if compilation has better performance? Well, in an environment without a persistent Perl interpreter like vanilla CGI this can actually be faster than a compiled approach since the startup cost is lower. The caching of Perl bytecode done by compilation systems is useless when the Perl interpreter doesn't stick around for more than one request.
There are other reasons too. Compiled Perl code takes up a lot of memory. If you have many unique templates, they can add up fast. Imagine how much RAM it would take up if every page that used server-side includes (SSI) had to stay in memory after it had been accessed. (Don't worry, the Apache::SSI module doesn't use compilation so it doesn't have this problem.)
1 以上我們所談論的樣版系統的解譯器是被導入到這3種方式(in-line perl, mini-language, DOM Tree)中的其中一種, 解譯器採用重複解譯方式, 解譯樣版內容然後快取緩存解譯樹的結果, 或者是解譯樣版內容再轉換成為perl的程式碼之後再予以編譯(compiled), 這2種方式
2 編譯(compiled)樣版成為perl的這些系統, 可讓perl的運作編碼時期的執行能力使得大大提升, 解譯器檢核樣版, 然後從樣版產生塊狀的perl程式碼及執行這些產生的程式碼, 在那之後, 隨著對這樣版的需求乃來自於編譯至記憶體中的位元碼
3 編譯(compiled)成perl然後成為perl 位元編碼在首次編譯是較慢的, 但是一旦該樣版被編譯完成則可提供極好的效能, 因為樣版則變成perl的次程序調用, 像 JSP(Java Server Pages)系統就是使用這相同的方法, 像mod_perl在perl長久執行編譯環境裡就有大大的效用
4 HTML::Template, HTML_Tree及釋出V2.0 beta 版本的Embperl也都是使用快取緩存解譯樹結果方式(cached parser tree), 這些模組或系統都是解譯樣版使它們的進入個別內部資料架構, 然後保留每個已處理已解譯架構在記憶體中, 實際上並不需要perl程式碼的生成, 因此也不需要執行(eval)階段, 快取緩存解譯樹結果(cached parser tree)或編譯(compiled), 哪一種方式是最快的呢?? 以客觀的估算來說它是比較困難的, 但從不可考的數據看起來似乎比較支援編譯(compiled)這種方式, 樣版工具包在版本1是使用快取緩存解譯樹結果方式(cached parse tree), 但在版本2是切換到編譯(compiled)方式, 稍後測試將展現它在增進速度上所提供的一種意義, 不管怎樣, 稍後再來好好討論, 任一方式都能有夠有更多的快速
5 在比對之下, 重覆解譯(repeated parse)方式可能聽起來會非常慢, 然而, 假使這標記(tokens)於一開始被解析它可能是比較快速的, 樣版系統會使用標記(tokens)方式, 一般來說都是採用非常簡易的標記, 並且允許它們可被快速使用及簡易地解譯
6 為什麼在你曾經所用系統有包含這個方式, 若在編譯有更好的效能?? , 當然, 在一個執行環境中我們並不需要一個反覆執行的perl編譯器就像 vanilla CGI, 事實上它比編譯方式更快速, 因為啟動的花費是較低的,當perl的編譯無法阻塞週邊一個以上的需求時, 對編譯系統來說完成快取緩存perl 位元程式碼(bytecode)作業是沒有用的
7 也有其它原因, 編譯perl的程式碼會佔用很多的記憶體, 假使你有很多的單獨的樣版, 記憶體會被快速的累加, 想像一下, 假使每一頁都使用server-side includes(SSI)方式儲存在記憶體中, 將有多少記憶體會被接管 (別擔心, Apache::SSI模組不會使用編譯方式, 如此它並不會有這個問題)
各式樣版引擎(模組)的介紹

SSI (Server-Side Includes)
SSI (Server Side Includes)是HTML頁面中的指令，在頁面被提供時由服務器進行運算，以對現有HTML頁面增加動態生成的內容，而無須通過CGI程序提供其整個頁面，或者使用其他動態技術。
對什麼時候用SSI，而什麼時候用某些程序生成整個頁面的權衡，取決於頁面中有多少內容是靜態，有多少內容需要在每次頁面被提供時重新計算。SSI是一種增加小段信息的好方法，諸如當前時間。如果你的頁面大部分是在被提供時生成的，那就要另找方案了。
SSI模組使用概述
1. 需確認Apach Server是否可使用SSI
2. 需在httpd.conf設定檔案配置服務器允許使用SSI
3. SSI指令有如下語法：

其格式很象HTML的注釋，因此如果沒有正確配置SSI，它會被瀏覽器忽略，但在HTML代碼中仍然可見。而如果正確配置了SSI，則此指令會被其結果替代。
詳細指令可參考以下連結
http://en.wikipedia.org/wiki/Server_Side_Includes
http://big5.chinaz.com:88/book.chinaz.com/PHP/apache2/howto/ssi.html
4. SSI可包含一個CGI的輸出(如: 點擊計數器), 其範例語法如下

5. 在PERL環境中可引用Apache::SSI 模組做為引用SSI, 一樣需在http.conf配置服務器允許使用SSI, 相關參考連結: http://search.cpan.org/~kwilliams/Apache-SSI-2.19/lib/Apache/SSI.pm
6. SSI網頁, 通常SSI的副檔名為 .shtml
7. SSI固然不能替代CGI或者其他動態頁面技術，但它是在頁面中插入眾多小型的動態片段的優秀方法，而無須大量額外的操作。
甲、優點 è
i. 是可將小段的動態內容放入現有的HTML網頁中, 而不需使用到CGI或其它動態的技術
ii. 可運作在Apache mod_perl環境下, 加速進程的存取速度
乙、缺點 è
i. 對於網頁的大部份內容皆是動態的, 則無法提供完善的技術, 倒是需採用CGI這類的技術來處理
ii. 因為使用SSI需改動現有的HTML網頁的副檔名為 .shtml , 所以需針對要採用SSI的網頁修改其副檔名
HTML::Template & Template Toolkit (pipeline管道模式)

HTML::Template 模組
1. HTML::Template概述
Perl module to use HTML Templates from CGI scripts

This module attempts to make using HTML templates simple and natural. It extends standard HTML with a few new HTML-esque tags - <TMPL_VAR>, <TMPL_LOOP>, <TMPL_INCLUDE>, <TMPL_IF>, <TMPL_ELSE> and <TMPL_UNLESS>. The file written with HTML and these new tags is called a template. It is usually saved separate from your script - possibly even created by someone else! Using this module you fill in the values for the variables, loops and branches declared in the template. This allows you to separate design - the HTML - from the data, which you generate in the Perl script.

使用來自CGI scripts的HTML樣版的perl模組

HTML::Template模組試著用簡易及自然的方式去使用HTML樣版, 該模組延伸出一些標準的HTML標籤, 如: <TMPL_VAR>, <TMPL_LOOP>, <TMPL_INCLUDE>, <TMPL_IF>, <TMPL_ELSE> and <TMPL_UNLESS>, 採用HTML及這些新標籤所編寫出的檔案則被稱為一個樣版, 而該樣版有可能是由你或別人所建立的, 它通常可避免你的script被打散, 使用HTML::Template模組可將樣版中的變數填入任何值, 或是在樣版中宣告迴圈或分支語法, 然而這個模組則將HTML與資料採分開設計方式, 而資料可由script生成

2. 相關資源參考
http://html-template.sourceforge.net/
http://search.cpan.org/dist/HTML-Template/Template.pm
http://search.cpan.org/~samtregar/HTML-Template-2.9/Template.pm

3. 範例說明
CGI (template1.pl)
my $template = HTML::Template->new(filename => template1.tmpl');
my @output;
for my $good (@goods)
{
my @attr = split(/,/, $_);
my %row = (
SHOE => $attr[0],
DETAILS => $attr[1],
PRICE => $attr[2],
QUANTITY => $attr[3],
);
push( @output, \%row );
}
$template->param(PRODUCT => \@output);
print $template->output();

樣版 (template1.tmpl)
<TMPL_LOOP NAME="PRODUCT">
<tr>
<td><TMPL_VAR NAME=SHOE></td>
<td><TMPL_VAR NAME=DETAILS></td>
<td><TMPL_VAR NAME=PRICE></td>
<td><TMPL_VAR NAME=QUANTITY></td>
</tr>
</TMPL_LOOP>

4. 總結
1.1 HTML::Template優點
1.1.1 樣版與程式完全分離, 以達到分工的效果
1.1.2 樣版的取用的控制乃由程式依現況自行引用所需的樣版
1.1.3 資料的來源的異動乃由程式那端取得資料內容
1.2 HTML::Template缺點
1.2.1 程式與樣版間的替換變數名稱需一致
1.2.2 樣版需使用mini-language(TMPL_VAR、TMPL_LOOP、TMPL_IF…等, 用於呼應程式的邏輯, 或自身的處理邏輯
1.2.3 樣版開發人員需學習mini-language各語法的使用,容造成樣版人員的負擔
1.2.4 對於變數的異動或新增無法透過設定方式, 告知另一方
1.3 樣版的副檔名為 .tmpl
1.4 程式中對於變數值的置換, 皆採用雜湊函數Key & Value做為一個Pair, 多筆置換則採用Referece Aarray方式
1.4.1 單一變數置換 è 以Hash方式處理
1.4.2 多筆資料變數置換 è 以Array方式參照Hash
1.5 樣版欲置換變數值或邏輯語法, 其前後需以<TMPL_VAR NAME=XXXX> 或 <TMPL_LOOP NAME=XXXX> 或 </TMPL_LOOP> 等特定的標示符(Token), 讓HTML::Template模組在讀進樣版時, 判讀到有特定字樣<TMPL_XXX NAME=XXXX> 或 </TMPL_XXX> 的Token時予以轉換成PERL的相對語法, 置換其變數之後再將結果送出

Template Toolkit
1 HTML::Template概述
The Template Toolkit (TT) is a fast and flexible template engine used primarily for building web sites but also suitable for any type of digital document creation like PDF or LaTeX. Template Toolkit, or TT for short, is based on a mini-language, rather than allowing direct perl like some of its competitors like Mason. This forces developers to only have presentation logic in their templates, and move business logic into perl libraries. It is written in Perl, with some popular accessories in C, and released under a free software licence (Perl Artistic Licence or GPL).

It's also a popular choice as templating system for various perl application frameworks, including the Catalyst MVC Framework, CGI::Application and the Maypole framework.

The Template Toolkit was written by Andy Wardley. The "prototype" for TT (the Text::MetaText Perl module) was released in 1996. The first version of TT proper was released in 1999. Version 2.00 was released in 2001. Version 3 is currently in development.

這個樣版工作套件是一種快速又有彈性的樣版引擎, 最主要被使用在建置網際網路站台, 但對於多元化文件型態(像PDF 或 LaTex)也是可適用的, 樣版工作套件(也可簡稱TT), 它是一種袖珍語言, 它並不像它的競爭對手(Mason)直接去引用perl, 反而是要求開發人員只可在他的樣版裡去展現邏輯性語法及輸入至perl libraries, 樣版工作套件是以perl語言去開發的, 它包含了一些較受歡迎C的附件, 以及可在GPL下發布

樣版工作套件在各式各樣PERL的應用程式框架中也是一種受歡迎的選擇, 它包含Catalyst MVC Framework, CGI::Application and the Maypole framework.

樣版工作套件是由Andy Wardley所編寫, 而TT的原型(Text::MetaText Perl module)乃在1996被提出發佈, 而TT的第1個版本則在1999年被發佈, 2.00版則在2001年被發佈, 至於第3版目前還在發展中

2. 相關資源參考
http://www.devshed.com/c/a/Perl/Getting-Started-with-the-Perl-Template-Toolkit/
http://www.perl.com/pub/a/2001/01/tt2.html
http://search.cpan.org/~abw/Template-Toolkit-2.19/lib/Template.pm

3. 範例說明
CGI (my_template.pl)
use Template;
my @teams = ({ name => 'Man Utd',
played => 16,
won => 12,
drawn => 3,
lost => 1 },
{ name => 'Bradford',
played => 16,
won => 2,
drawn => 5,
lost => 9 });
my %data = ( name => 'English Premier League',
season => '2000/01',
teams => \@teams );

my $tt = Template->new;
$tt->process('my_template.html', \%data) die $tt->error;

樣版 (my_template.html)
League Standings League Name: [% name %] Season : [% season %] Teams: [% FOREACH team = teams %] [% team.name %] [% team.played %] [% team.won %] [% team.drawn %] [% team.lost %]
[% END %]

輸出結果 (result)
League Standings League Name: English Premier League Season : 2000/01 Teams: Man Utd 16 12 3 1
Bradford 16 2 5 9

5. 總結
1.1 Template Toolkit優點
1.1.1 樣版與程式完全分離, 以達到分工的效果
1.1.2 樣版的取用的控制乃由程式依現況自行引用所需的樣版
1.1.3 資料的來源的異動乃由程式那端取得資料內容
1.1.4 CGI在解析處理樣版時, 採用process方法, 第一個參數為來源樣版, 第2個參數則為樣版中要被替換變數的內容值, 如: process('my_template.html', \%data), 第2參數可為Variable, Reference Hash, Reference Array List, Reference Subfunction, Object…等
1.2 Template Toolkit缺點
1.2.1 程式與樣版間的替換變數名稱需一致
1.2.2 樣版需使用mini-language([% FOREACH %] …… [% END %]、[% IF %]…… [% END %]……等等), 用於呼應程式的邏輯, 或自身的處理邏輯
1.2.3 樣版開發人員需學習mini-language各語法的使用,容造成樣版人員的負擔
1.2.4 對於變數的異動或新增無法透過設定方式, 告知另一方
1.3 樣版欲置換變數值或邏輯語法, 其前後需以[% …… %] 特定的標示符(Token), 讓Template Toolkit模組在讀進樣版時, 判讀到有特定字樣[% …… %] 的Token時予以轉換成PERL的相對語法, 置換其變數之後再將結果送出

Text:: Template模組
1. Text::Template概述
This module has become the de facto standard general purpose templating module on CPAN. It has an easy interface and thorough documentation. The examples in the docs show a pipeline execution style, but it's easy to write a mod_perl handler that directly invokes templates, allowing a callback style. The module uses in-line Perl. It has the ability to run the in-line code in a Safe compartment, in case you are concerned about mistakes in the code crashing your server.
The module relies on creative uses of in-line code to provide things that people usually expect from templating tools, like includes. This can be good or bad. For example, to include a file you could just call Text::Template::fill_in_file(filename). However, you'll have to specify the complete file path and nothing will stop you from using /etc/passwd as the file to be included. Most of the fancier templating tools have concepts like include paths, which allow you to specify a list of directories to search for included files. You could write a subroutine that works this way, and make it available in your template's namespace, but it's not built in.
Each template is loaded as a separate object. Templates are compiled to Perl and only parsed the first time they are used. However, to take full advantage of this caching in a persistent environment like mod_perl, your program will have to keep track of which templates have been used, since Text::Template does not have a way of globally tracking this and returning cached templates when possible.
Text::Template is not tied to HTML, and is just a templating module, not a web application framework. It is perfectly at home generating e-mails, PDFs, etc.

Text::Template已變成CPAN普遍使用的標準元素, 它有容易操作的介面及完善的說明文件, 在這些文件中的範例是採用pipeline型式做為執行的方法, 因此它很容易去編輯mod_perl handler, 讓mod_perl handler直接引用樣版, 及允許執行ballback(回呼)模式, 這模組也是使用in-line perl方式, 該模組有能力去執行在一塊安全區間中的in-line程式碼, 免得你會擔心該程式碼造成Server crash的問題
Text::Template模組依附著in-line程式碼所提供的事務, 啟發想像的功效, 人們通常都預期它會由樣版工具而來, 就像 includes, 它會是好的也是壞的, 舉例來說, 去包含一個檔案, 你只需要呼叫Text::Template::fill_in_fil(filname)這個檔組, 然而, 你將需要去制訂完整的檔案路徑以及沒有任何事可讓你停止來自於使用/etc/passwd如同一個檔案般被包括, 大多數樣版工具愛好者都有著像目錄包含的概念, 這將允許你去制定大量的目錄用於搜尋所包含的檔案, 你也可以編輯一個subroutine去執行這個想法以及使得它在你的樣版命名空間更有價值, 但它不是內嵌的
每個樣版都被引用成一個分散的物件, 樣版被編譯到perl裡及於首次被使用時只需解析它, 然而, 快取緩存在一個反覆不斷的環境中可獲得更完整的效益, 如: mod_perl, 你的程式將會持續保持追踪哪個樣是被使用的, 因此, Text::Template無法對全域性的追踪有任何一種方法及返回已緩存的樣版
Text::Template模組與HTML是不聯繫在一起的, 它僅只是一個打樣模組而已, 並不是一個web application framework, 它專注在生成e-mails, PDFs….等等

2. 相關資源參考
http://search.cpan.org/~mjd/Text-Template-1.45/lib/Text/Template.pm

3. 範例說明
CGI (formletter.pl)
use Text::Template;

my $template = Text::Template->new(SOURCE => 'formletter.tmpl')
or die "Couldn't construct template: $Text::Template::ERROR";

my @monthname = qw(January February March April May June
July August September October November December);
my %vars = (title => 'Mr.',
firstname => 'Bill',
lastname => 'Gates',
last_paid_month => 1, # February
amount => 392.12,
monthname => \@monthname,
);

my $result = $template->fill_in(HASH => \%vars);

if (defined $result) { print $result }
else { die "Couldn't fill in template: $Text::Template::ERROR" }

樣版 (formletter.tmpl)
Dear {$title} {$lastname},

It has come to our attention that you are delinquent in your
{$monthname[$last_paid_month]} payment. Please remit
${sprintf("%.2f", $amount)} immediately, or your patellae may
be needlessly endangered.

Love,
Mark "Vizopteryx" Dominus

輸出結果 (result)
Dear Mr. Gates,

It has come to our attention that you are delinquent in your
February payment. Please remit
$392.12 immediately, or your patellae may
be needlessly endangered.

Love,
Mark "Vizopteryx" Dominus

2. 總結
1.1 Text::Template優點
1.1.1 樣版與程式完全分離, 以達到分工的效果
1.1.2 樣版的取用的控制乃由程式依現況自行引用所需的樣版
1.1.3 資料的來源的異動乃由程式那端取得資料內容
1.2 Text::Template缺點
1.2.1 程式與樣版間的替換變數名稱需一致
1.2.2 該模組大多運用於mail的顯示格式, 無法處理多筆置換變數, 所以無法運用在商業行為的網頁
1.2.3 對於變數的異動或新增無法透過設定方式, 告知另一方
1.3 樣版欲置換變數值或邏輯語法, 其前後需以{$XXXX} 特定的標示符(Token), 讓Template Toolkit模組在讀進樣版時, 判讀到有特定字樣{$XXXX} 的Token時予以轉換成PERL的相對語法, 置換其變數之後再將結果送出
1.4 樣版的副檔名需為tmpl

採用Pipeline(管道)模式進行樣版解析各Perl模組summary
l Template Toolkit 與 Text::Template皆在樣版中嵌入供解析用的Token
1. HTML::Template：<TMPL_VAR NAME=XXXX> 或 </TMPL_LOOP> 做為解析標準
2. Template Toolkit Token： [% XXX %]
3. Text::Template Token： {$XXX}
l 替換之變數名稱
1. Template Toolkit: 無前綴 $ 符號
2. Text::Template: 需前綴 $ 符號
l Template Toolkit 與 Text::Template 與 HTML::Template的CGI與樣版中欲被替換的變數名稱皆需一致
l Template Toolkit 與 HTML::Template對於條件式語法(conditional)或循環資料語法(loop)皆有其特定專用語法陳述
1. Template Toolkit：GET、CALL、SET、DEFAULT、INSERT、INCLUDE、PROCESS、WRAPPER、BLOCK、FOREACH、FOREACH …….. END、WHILE.......END、IF/UNLESS/ELSIF/ELSE …….. END、SWITCH/CASE …….. END、MACRO ……..等等, 可參考CPAN上有關該模組的使用
2. HTML::Template：<TMPL_VAR> 、 <TMPL_LOOP> 、 <TMPL_INCLUDE> 、<TMPL_IF> 、 <TMPL_ELSE> 、 <TMPL_UNLESS>
l Text::Template無法達到Web應用上多筆資料顯示模式(只限處理單純文字替換模式)
l Template Toolkit 與 Text::Template 與 HTML::Template這3種模組都可將CGI及樣版的維護各自分離, 使程式人員與樣版人員可各自處理相關異動或維護, 較不會交雜在一起(但前提是替換的變數需做事先規劃)
l 雖然套用以上3種模組可將程式與樣版各自切割出去對系統架構來說是好的(也就是各自維護各自的檔案, 不用互相牽制(但事先要先規劃好替換變數的規格), 但這3種模式看起來應不適用於公司未來套用的架構, 其分析原因如下
1. Text::Template看起來較為簡單, 但只限單純文字替換模式, 無法因應web多變狀況的運用
2. Template Toolkit對於樣版的維護人員必需充份了解專用語法的意義, 對樣版維護相關人員來說是一個負擔
3. HTML::Template看來較為簡單, 但對樣版來說同樣有著專用語法的應用

HTML::Mason & HTML::Embperl & (callback回呼模式)

Callback模式摘要
1. 可交雜perl程式碼於樣版中(也就是交由樣版接管, 並將應用程序控制碼編入HTML中), 執行該樣版中的perl程式碼則會回撥至perl
2. Callback模式對於程式設計人員來說是可以簡單方式達到效益, 但其模式的缺點為若程式設計人員與樣版設計人員不為同一人時, 會造成2人同時維護同一個檔案, 造成維護上的困難

HTML::Mason模組
1. Text::Template概述
Mason has been around for a few years now, and has built up a loyal following. It was originally created as a Perl clone of some of the most interesting features from Vignette StoryServer, but has since become it's own unique animal. It comes from a publishing background, and includes features oriented towards splitting up pages into re-useable chunks, or "components."
Mason uses in-line Perl with a compilation approach, but has a feature to help keep the perl code out of the HTML coder's way. Components (templates) can include a section of Perl at the end of the file which is wrapped inside a special tag indicating that it should be run first, before the rest of the template. This allows programmers to put all the logic for a component down at the bottom away from the HTML, and then use short in-line Perl snippets in the HTML to insert values, loop through lists, etc.
Mason is a site development framework, not just a templating tool. It includes a very handy caching feature that can be used for capturing the output of components or simply storing data that is expensive to compute. It is currently the only tool that offers this sort of caching as a built-in. It also implements an argument parsing scheme which allows a component to specify the names, types, and default values that it expects to be passed, either from another component or from the values passed in the URI query string.
While the documentation mostly demonstrates a callback execution model, it is possible to use Mason in a pipeline style. This can be accomplished in various ways, including designating components as "autohandlers" which run before anything else for requests within a certain directory structure. An autohandler could do some processing and set up data for a display template which only includes minimal in-line Perl. There is also support for an object-oriented site approach, applying concepts like inheritance to the site directory structure. For example, the component at /store/book/ might inherit a standard layout from the component at /store/, but override the background color and navigation bar. Then /store/music/ can do the same, with a different color. This can be a very powerful paradigm for developing large sites.
Mason's approach to debugging is to create "debug files" which run Mason outside of a web server environment, providing a fake web request and activating the debugger. This can be helpful if you're having trouble getting Apache::DB to behave under mod_perl, or using an execution environment that doesn't provide built-in debugger support.
Another unique feature is the ability to leave the static text parts of a large template on disk, and pull them in with a file seek when needed rather than keeping them in RAM. This exchanges some speed for a significant savings in memory when dealing with templates that are mostly static text.
There are many other features in this package, including filtering of HTML output and a page previewing utility. Session support is not built-in, but a simple example showing how to integrate with Apache::Session is included. Mason's feature set can be a bit overwhelming for newbies, but the high-quality documentation and helpful user community go a long way
Mason使用至今已有很多年了, 至今也建立了很多忠實的追隨者, 它起初被建造成為如Perl的複制品, 某些最有趣的特點乃來自Vignette SotryServer, 但是後來變成獨樹一格了, 來自於一種發表中的後台, 並且包含以分散頁面為導向, 使它成為是可重覆使用的區塊或元件(components)之特點
Mason使用in-line Perl(內含perl程式碼)做為一種編譯方式, 但有一個特點乃持續輔助perl的程式碼避開HTML編碼器的模式, 在檔案的最後, 元件(樣版)則包含perl的序列(section), 這序列是被包複在一個特殊標籤中, 在其餘樣版之前, 指出它應該首先被執行, 這將允許程式設計師可順沿著html的底部對著一個元件(樣版)放入所有的邏輯碼, 然後在HTML頁面中使用簡短的 in-line Perl (內含perl程式碼)片段去新增變數值, 循環資料清單(loop)….等
Mason是一個站台的開發框架, 不僅僅是個樣版工具而已, 它包含一個非常輕量快取緩存的特點, 這特點能被用在對元件(樣版)輸出的快取緩存或以簡易儲存高價計算的資料, Mason是目前最好的工具, 除了提供視為嵌入快取緩存排序功能, 也是一種解析參數schema的工具, Mason允許一個元件(樣版)可去規劃制訂預計將被傳遞的names(名稱), types(型態) 及 default values(預設值), 甚至來自其它元件或來自於URI查詢字串中所傳遞的值
當一份說明文件大多數都使用callback(回呼)執行模式, 在pipeline(管道)型式中使用Mason是可能的, 在各種方式下它都可被完成, 包含在任何事情之前被執行, 指派元件(樣版)成為一個“autohandlers(自動操控者)” 般, 除非對於包含在某些目錄架構中的需求, 一個autohandlers(自動操控者)可執行一些程序, 以及為一份做為展示用的樣版(僅包含微量的in-line perl[線內perl程式碼])來設定資料, 對於一個以OO(object-oriented)的站台入口也是支援的, 應用的概念就像去繼承這站台的目錄架構, 舉例來說, 一個在 /store/book/目錄下的元件(樣版)是可繼承來自於/store/目錄下元件(樣版)的標準編排設計, 但卻可推翻原背景顏色及導航桿(navigation bar), 因此 /store/music/目錄下的元件(樣版)也可這樣做, 有一個不同的顏色, 對於開發一個大型的站台來說, 這是將是一個強而有力的例子
執行Mason在一個web server環境之外, Mason對於除錯(debugging)的方法就是去建置 “debug files (除錯檔案)” , 提供一個假的web需求及活動中的除錯者, 這將給予你很大的幫助, 假使你在mod_perl環境下取得Apache::DB的行為有發生問題的話, 或是你正在使用一個執行環境, 而該環境是沒有提供崁入式除錯者支援
其它唯一的特色是將在disk上大型樣版的靜態文字部份予以去除的能力, 以及當需要它們的時候把它們放在一個檔案上, 而不是繼續保存在記憶體(RAM)裡, 當處理有著大量靜態文字的樣版時, 這能改變部份的速度對於存放在記憶體中重大的事物

有很多其它特色在這份套件中, 包括過濾html輸出及一個頁面預覽的功能, Sessionsupport是不被崁入的, 但一個簡單的範例將展示如何把Apache::Sesion整合包含進來, Mason的特色組合對於網路新手來說能有些勢不可擋, 但高品質使用說明及對使用社群有著長久的助益

2. 相關資源參考
http://www.masonhq.com/ è 想多了解mason的可參考這個網站
http://www.masonbook.com/ è O’Reilly針對mason所出的原文書
http://search.cpan.org/~jswartz/HTML-Mason-1.05/lib/HTML/Mason.pod

3. 範例說明
CGI (template1.pl)
1. 類似ASP, 於% … % 或 <% …… %> 區塊則為執行程式碼或置換輸出值的地方
2. 需被執行的程式碼需前綴 % 符號以表示
% for my $good (@goods) {
% my @attr = split(/,/, $good);
% my $quantity = $attr[3] eq '0' ? 'Out of stock' : $attr[3];
<tr>
<td><% $attr[0] %></td>
<td><% $attr[1] %></td>
<td><% $attr[2] %></td>
<td><% $quantity %></td>
</tr>
% }

2. 總結
Mason是一種強而有力以perl為base用於web站台開發及傳送資料的引擎, 你可嵌
入perl的程式碼在HTML文件中及建構出分享頁面及重覆使用元件(樣版)

Mason可解決一般站台開發所遭遇的問題, 如: 快取緩存, 除錯, 打樣, 開發維護及
製作站台…等等問題

Mason是一個100%自由及開放原始碼, 因此它能被CGI所使用或者甚至獨立使用,
由於使用了2項其它開放源始碼技術: mod_perl及Apache, 使得Mason被設計的最
佳化的
1. Mason可解決高負載站台在處理動態內容的效率(如: 線上新聞, 線上購物…等)
2. Mason的最初建立乃為web站台而生
3. Mason是以components概念做為主軸, components是一個交雜html, perl 及 Mason自訂的指令組合而成的一個檔案
4. 以<%.......%>做為替換值的處理方式
5. 在一行程式碼前放置%表示該行將會以perl的方式處理, 但該語法需以perl的正規語法表示
6. 要使用HTML::Mason這個模組, 需對httpd.conf設定增加一些設定內容
PerlModule HTML::Mason::ApacheHandler
<Location />
SetHandler perl-script
PerlHandler HTML::Mason::ApacheHandler
</Location>

HTML::Embper模組
1 Text::Template概述
Embperl makes its language choice known up front: embedded perl. It is one of the most popular in-line Perl templating tools and has been around longer than most of the others. It has a solid reputation for speed and ease of use.
It is commonly used in a callback style, with Embperl intercepting URIs and processing the requested file. However, it can optionally be invoked through a subroutine call from another program, allowing it to be used in a pipeline style. Templates are compiled to Perl bytecode and cached.
Embperl has been around long enough to build up an impressive list of features. It has the ability to run code inside a Safe compartment, support for automatically cleaning up globals to make mod_perl coding easier, and extensive debugging tools including the ability to e-mail errors to an administrator.
The main thing that sets Embperl apart from other in-line Perl systems is its tight HTML integration. It can recognize TABLE tags and automatically iterate over them for the length of an array. It automatically provides sticky form widgets. An array or hash reference placed at the end of a query string in an HREF or SRC attribute will be automatically expanded into query string "name=value" format. META HTTP-EQUIV tags are turned into true HTTP headers.
Another reason people like Embperl is that it makes some of the common tasks of web application coding so simple. For example, all form data is always available just by reading the magic variable %fdat. Sessions are supported just as easily, by reading and writing to the magic %udat hash. There is also a hash for storing persistent application state. HTML-escaping is automatic (though it can be toggled on and off).
Embperl includes something called EmbperlObject, which allows you to apply OO concepts to your site hierarchy in a similar way to the inheritance features mentioned for Mason, above. This is a very convenient way to code sites with styles that vary by area, and is worth checking out.
One drawback of older versions of Embperl was the necessity to use built-in replacements for most of Perl's control structures like "if" and "foreach" when they are being wrapped around non-Perl sections. For example:
Embperl制作屬於它自己的語言選項, 就像前面已知的: 嵌入perl程式碼, 它是in-line perl(內含perl程式碼)最受歡迎的打樣工具中的一種, 對於大多數其它工具它已運作的更長久了
Embperl最常使用在callback(回呼)模式中, 用於截取URI及處理被請求的檔案, 然而, 它會被由其它程式經過一個subroutine call選擇性的被引用, 也允許在pipeline模式下可被使用, 樣版是被編譯成perl位元程式碼及快取緩存的;
Embperl已運作長久了足夠可去建立一個另人感到欽佩的特點清單, 它有能力在一塊安全區塊內執行程式碼, 並支援自動化清除全域資料去使得mod_perl的編譯更為容易, 以及廣大的除錯工具包含向管理者傳遞錯誤的能力
最主要的事情則是Embperl可被獨立的設立, 其它in-line perl的系統是將它與html緊緊結合在一起, 它可以重組TABLE標籤及對於一個有長度的陣列則自動化的重複它們它也提供固定的表格介面小工具, 一個陣列或雜湊函數參照被放置在一個查詢字串的末端, HREF或SRC屬性將被自動的擴展成為查詢字串 “name=value” 格式, META HTTP-EQUIV標籤使它成為真實的HTTP標頭
人們喜歡Embperl的其它理由是它使得某些web application編碼常態性的工作變得如此的簡單, 舉例來說, 所有的表單資料是永遠有效的僅僅來自於讀取這魔幻般的%fdat變數, Sessions也是如此簡單的被支援, 來自於讀寫成魔幻般的%udat雜湊函數, 對於儲存不間斷的應用狀態也有一個雜湊函數支援, HTML-escaping是自動化的
Embperl包含了些許EmbperlObject的叫用, 它允許你對你的站台階層去運用OO概念,這類似的方法如先前所提到的Mason繼承特點, 這是一種非常方便的方法去編輯來自於不同區域的站台與型態及檢查的價值
當樣版開始循序環繞非perl 區塊, Embperl舊版的某個缺點是它必需對於大部份perl控制架構去使用嵌入置換方式, 如: if 及 foreach , 舉例來說
[$ if ($foo) $]
Looks like a foo!
[$ else $]
Nope, it's a bar.
[$ endif $]
These may seem out of place in a system based around in-line Perl. As of version 1.2b2, it is possible to use Perl's standard syntax instead:
在一個運作於in-line perl系統中, 使用if 語法有些看起來似乎不是很適合, 如: 1.2 beta 2版本, 它有可能使用perl的標準語法去取代之
[$ if ($foo) { $]
Looks like a foo!
[$ } else { $]
Nope, it's a bar.
[$ } $]
At the time of this writing, a new 2.x branch of Embperl is in beta testing. This includes some interesting features like a more flexible parsing scheme which can be modified to users' tastes. it also supports direct use of the Perl debugger on Embperl templates, and provides performance improvements.
在編寫的這個時點, Embperl新版2.X分支已在beta測試中, 它包括了些許有趣的特點, 如更有彈性解析概要, 它可異動維護使用者的感受, 它也可支援在Embperl樣版中直接使用除錯器, 以及提供效能的改善
相關資源參考
http://www.moon-soft.com/program/bbs/readelite9500.htm ==> 這裡有對embperl及fcgi有一些看法, 可參考看看

Apache::ASP
Apache::ASP started out as a port of Microsoft's Active Server Pages technology, and its basic design still follows that model. It uses in-line Perl with a compilation approach, and provides a set of simple objects for accessing the request information and formulating a response. Scripts written for Microsoft's ASP using Perl (via ActiveState's PerlScript) can usually be run on this system without changes. (Pages written in VBScript are not supported.)
Like the original ASP, it has hooks for calling specified code when certain events are triggered, such as the start of a new user session. It also provides the same easy-to-use state and session management. Storing and retrieving state data for a whole application or a specific user is as simple as a single method call. It can even support user sessions without cookies by munging URLs -- a unique feature among these systems.
A significant addition that did not come from Microsoft ASP is the XML and XSLT support. There are two options provided: XMLSubs and XSLT transforms. XMLSubs is a way of adding custom tags to your pages. It maps XML tags to your subroutines, so that you can add something like <site:header page="Page Title" /> to your pages and have it translate into a subroutine call like &site::header({title => "Page Title"}). It can handle processing XML tags with body text as well.
The XSLT support allows the output of ASP scripts to be filtered through XSLT for presentation. This allows your ASP scripts to generate XML data and then format that data with a separate XSL stylesheet. This support is provided through integration with the XML::XSLT module.
Apache::ASP provides sticky widgets for forms through the use of the HTML::FillInForm module. It also has built-in support for removing extra whitespace from generated output, gzip compressing output (for browsers that support it), tracking performance using Time::HiRes, automatically mailing error messages to an administrator, and many other conveniences and tuning options. This is a mature package which has evolved to handle real-world problems.
One thing to note about the session and state management in this system is that it currently only supports clusters through the use of network filesystems like NFS or SMB. (Joshua Chamas, the module's author, has reported much better results from Samba file-sharing than from NFS.) This may be an issue for large-scale server clusters, which usually rely on a relational database for network storage of sessions. Support database storage of sessions is planned for a future release.
Apache::ASP是以Microsoft’s Active Server Pages技術窗口為出發的, 它最基本的設定仍然追隨著這個模式, 它使用in-line perl(內容perl程式區塊)包含編譯方式, 以及提供一組對於存取請求資訊和回應的規劃的簡化物件, 在Microsoft’s ASP方面Scripts採用Perl(via ActiveState’s PerlScript)做為編寫方式, 它通常執行這個系統不需做任何的變更(Pages written in VBScript are not supported)
像原始的ASP, 當已被確認的事件被觸發時, 對於正被呼叫明確程式它以掛鈎方式, 就像啟動一個新使用者的session一般, 它也提供相同的輕鬆簡單方式去使用狀態及session管理, 儲存及接收狀態資料對於一整個應用程式或一個特定的使用者來說是一個極其簡單的單項方式呼叫, 它甚至也支援使用者session不用cookies來自於munging URLs – (一項獨特的特點在這些系統之間)
來自Microsoft ASP的一項值得注意事項是不支援XML及XSLT, 有2個選項被提供: XMLSubs及XSLT轉換, XMLSubs是一項新增客制的標籤(Tages)到你頁面的方法, 它勘測XML標籤到你的Subroutines, 因此你能增加某些像<site:headerpage=”Page Title”/>這樣的標籤到的頁面及使其轉換到Subroutine呼叫就像 &site::header({title => “Page Title”}), 它也能去管控處理好XML的BODY標籤
XSLT也支援ASP scripts的輸出展示是經過XSLT的過濾, 這準許你的ASP scripts去生成XML資料以及編排資料順應XSL stylesheet做為區分, 它被提供整合在XML::SXLT模組中
Apache::ASP也提供一些固定性的小工具, 對於表格憑藉使用的HTML::FilllnForm模組, 它是內嵌式支援於移除額外的空白, 對於整合性的輸出, 壓縮gzip輸出(因流覽器是支援它的), 追踨效能是使用Time::HiRes, 自動化的郵寄錯誤訊息給管理者, 以及有許多其它的便利及調校選項, 這是一個完善的套件, 它已發展成可管控真實世界的問題
有一件值得注意的是在這系統中session及state的管理, 在目前僅支援群組直接使用網路的檔案系統, 就像NFS or SMB(Joshua Chamas,這模組的作者, 已發表很多對於檔案分享[file-sharing]來自於Samba比來自NFS更好的結果文章), 對於大範圍伺服器的群組這可能是個爭議, 對於網路貯放session通常依附在一個relational資料庫, 支援資料庫貯放session的被計劃在未來被釋出
相關資源參考
http://search.cpan.org/~chamas/Apache-ASP-2.61/ASP.pm
http://www.apache-asp.org/

3. 範例說明
A simple asp page would look like:


<html>
<body>
For loop incrementing font size: <p>
<% for(1..5) { %>

<font size="<%=$_%>" > Size = <%=$_%> </font> <br>
<% } %>
</body>
</html>


4. 結論
1. Apache::ASP能夠讓Apache Web Server只用perl語言就可以支持ASP, 這對使用ASP的開發者來說是好的, 它可以用來開發動態網頁應用程序, 而且具有強大的擴展性, 包含了XML及XSLT解譯器, 讓開發者不必改寫原始的ASP API
2. 運用Apache::ASP模組, 雖然不必改寫原來的ASP, 但有2件需要注意的事項
i. <% XXXXX %> è 運行PERL程式碼的區塊
ii. <%= XXXXX %> è 程式運行中替換值
3. Apache::ASP增加XMLSub選項, 可自由去增加特定客制標籤(Tags)
4. Apache::ASP增加XLST轉換, 該資料的輸出是可經過XSLT的過濾及編排

其它
 AxKit2
Previous versions of this document covered Apache::AxKit. However, the coverage was not very good and that project has since been replaced by AxKit2.
Like its predecessor, AxKit2 is all about XML. It is more of a framework than a templating system per se, but includes support for multiple templating systems within it. The systems supported in the core release include XSLT, TAL (see the notes on Petal and Template::TAL below), XSP, an XML-based mini-language which can be extended with your own tags, and facilities for writing custom tag libraries.
Rather than short-change AxKit2 here with an inadequate description, I would encourage people who are intrigued by what they've heard so far to go and check out AxKit2 on CPAN. If you like working with XML, this may be a very good fit for you.
1. AxKit2對於開發環境都在XML的開發人員來說, 這個模組可專門運用在XML開發環境中
 HTML_Tree
As mentioned earlier, HTML Tree uses a fairly unique method of templating: it loads in an HTML page, parses it to a DOM, and then programmatically modifies the contents of nodes. This allows it to use genuine valid HTML documents as templates, something which none of these other modules can do. The learning curve is a little steeper than average, but this may be just the thing if you are concerned about keeping things simple for your HTML coders. Unfortunately, HTML_Tree seems to be a dead project at this point and has not had an update in years. (Note that the name is "HTML_Tree", not "HTML::Tree".)
1. 把整份HTML頁面LOAD進來, 再把它轉換成DOM, 然後再對每個節點的內容予以程式化的修正
2. 壞處是在這几年裡, 該模組較少被更新了
 Petal and Template::TAL
Both of these modules are based on the TAL templating language created by the developers of the (Python) Zope CMS. (Petal offers some additions, while Template::TAL tries to be a strict implementation of the TAL spec.) The basic idea is to make your templates XML documents and use attributes in a TAL namepace to specify data, loops, and conditionals. This means it is essentially using a mini-language, but the templates end up being valid XML documents, which allows them to be edited with XML tools.
There are a couple of downsides to TAL. One is the verbosity. Compared to most of the other tools listed here, TAL is very verbose. This is a consequence of using XML attributes for everything. Here's an example from the Template::TAL docs:
<li tal:repeat="user users">
<a href="?" tal:attributes="href user/url"><span tal:replace="user/name"/></a>
</li>
The other issue is the need for your templates to be valid XML (most likely XHTML). Petal attempts to be more forgiving by implementing a custom parser and allowing XHTML and HTML. This should allow the use of WYSIWYG tools to edit templates. In practice though, the custom parser is easily confused by HTML that browsers would handle without a problem. A custom parser is also problematic from a maintenance perspective since it doesn't benefit from improvements in the commonly used XML parsers. Template::TAL uses XML::LibXML.
Both Petal and Template::TAL have seen relatively recent maintenance releases, which makes them a much safer bet than HTML_Tree at this point.
1. 合適於Python語言開發人員使用
 ePerl
Possibly the first module to embed Perl code in a text or HTML file, ePerl is getting a bit long in the tooth. The mod_perl-aware version, Apache::ePerl, caches compiled bytecode in memory to achieve solid performance, and some people find it refreshingly simple to use. However, it lacks many of the features that the other more modern systems have, and may be difficult to compile on recent versions of Perl.
1. ePerl可謂第一個嵌入Perl程式碼在Text或HTML檔案中的第一個模組
2. Apache::ePerl, mod_perl必需的版本, 快取緩存位元碼在記憶體中, 以強化存取效能及讓人們可更簡易的去使用
3. ePerl模組的缺點對於現在perl的版本, 是不容易被編譯的
 CGI::FastTemplate
This module takes a minimalistic approach to templating, which makes it unusually well suited to use in CGI programs. It parses templates with a single regular expression and does not support anything in templates beyond simple variable interpolation. Loops are handled by including the output of other templates. Unfortunately, this leads to a Perl coding style that is more confusing than most, and a proliferation of template files. However, some people swear by this dirt-simple approach.
1. CGI::FastTemplate模組通常適用在CGI程式中
2. 以Regular Expression方式解析樣板

Template::Recall (Reverse Callback)
樣版與perl程式碼是被完全切割的, 樣版是由 sections 所組合而成, perl程式碼於執行時則呼叫這些sections並分析它, 該模式類以pipeline模式而與callback模式是相反的, Sections在樣版是非常重要的, 可引用perl模組 Template::Recall, 該模組使用預設parttern /[\s*=+\s*\w+\s*=+\s*]/ 去match樣版中符合[==== section_name ====]的字樣後再使用split() 方式去分割這些正規化的section, 並將\w+視為section key, 並以render method將該section中符合 ‘[‘ and ‘]’字樣的變數予以取代成欲顯示的值

template1.pl
my @goods = (
"oxfords,Brown leather,\$85,0",
"hiking,All sizes,\$55,7",
"tennis shoes,Women's sizes,\$35,15",
"flip flops,Colors of the rainbow,\$7,90"
);

1. 呼叫外部樣版, 建置物件
use Template::Recall;

my $tr = Template::Recall->new( template_path => 'template1.html');

2. call render方法, 分析header section中欲被替換的變數, 欲取代的key及value需存放在hash函數中, 但前提是hash中的key需與樣版中的’[‘Names’]’變數相符合才可版置換
print $tr->render( 'header', { title => 'MyStore', date => scalar(localtime) } );

3. 分析goods陣列中的每筆資料, 並將資料轉換成樣版中Table中的每一筆資料, 而事實上, array的資料來源也可由DataBase而來, 在這裡也一樣call render method來置換樣版中每個欄位的值, 而值的替換也是採用hash方式來處理
for my $good (@goods)
{
my @attr = split(/,/, $good);
my $quantity = $attr[3] eq '0' ? 'Out of stock' : $attr[3];

my %row = (
shoe => $attr[0],
details => $attr[1],
price => $attr[2],
quantity => $quantity,
);

print $tr->render('product_row', \%row);
}

4. 最後分析footer section, 該section並不需要傳入任何要替換的值, 則可不必傳入替代用的hash值
print $tr->render('footer');

template1.html
[ =================== header ===================]

<html>
<head>
<title>my site - [' title ']</title>
</head>
<body>

<h4>The date is [' date ']</h4>

<table border="1">

<tr>
<th>Shoe</th>
<th>Details</th>
<th>Price</th>
<th>Quantity</th>
</tr>

[ =================== product_row =================== ]
<tr>
<td>[' shoe ']</td>
<td>[' details ']</td>
<td>[' price ']</td>
<td>[' quantity ']</td>
</tr>

[= footer =]
</table>

</body>
</html>

輸出結果

微人資訊

我的雲端生活網 - Life+

Friday, June 20, 2008

修正與補充--為何 Fiddler2可以Decrypt captured SSL packets?

Wednesday, June 18, 2008

為何 Fiddler2可以Decrypt captured SSL packets?

Wednesday, June 11, 2008

[微程式-技術研討會] 6月研討會 - 主講人Lucy - 社群網站(orkut)分享

[微程式-技術研討會] 6月研討會 - 主講人vivian - 樣版系統相關簡介

Blog Archive