[英]Why choose an XSL-transformation?
對於當前項目，必須決定是使用XML和XSL轉換來生成HTML還是直接使用HTML模板。
我對支持或反對XSL方法的論據感興趣。 我知道，在你必須支持許多不同布局的情況下，XSL解決方案有很多優點，但為什么在那些只需支持一個目標布局的情況下你會選擇它？
編輯：我們在這里談論Java。
XSLT是一種函數式編程語言，您可以使用它來創建與任何模板系統一樣豐富的前端。 但是，你不應該 - 你和你的團隊會瘋狂。
這兩個選項都提供了以邏輯方式將對象轉換為表示形式的機會。 XSLT最適合創建更多XML，這可能會讓您相信它是用於創建XHTML的完美候選者。 但是，創建XHTML不應該是主要目標 - 創建用戶體驗是。 不要關心媒體 。
XSLT的兩個顯着缺點涉及語法：您的模板及其包含的模板以及這些模板包含的模板都將是巨大而冗長的。 其次，你將不得不做很多函數式編程，當遇到帶有累積函數參數的遞歸模板而不是簡單的for循環時，經驗不足的工程師可能會感到困惑和害怕。
如果您被改造邏輯構造的有效XML實體的美感所吸引，那么請考慮使用類型安全的模板系統來轉換bean。 查看Google XML頁面 ，創建邏輯組織的，類型安全的模板，以便將來的工程師輕松選擇和擴展。
我大約5年前為企業產品創建了一個XML / XSLT驅動的UI。 我們仍在使用它，現在我可以回顧一下我的經驗並看到許多利弊：
優點：
缺點：
當我想到更多問題時，我會嘗試更新。 我認為現在回顧一下，我的判斷是堅持使用通用的模板語言。 我選擇XML / XSLT時曾經遇到的大問題現在已經被主要模板引擎的更新和更成熟的版本所解決。 我們仍然可以從繼承.xslt文件的能力中獲益，這是大多數模板引擎都做不好的事情。 但最終，許多開發人員提供示例的價值要大得多（例如，比較ASP.NET答案與StackOverflow上的XSLT答案。）
希望有所幫助！
我使用XSLT進行了重要的開發，它在兩個不同的站點都取得了巨大的成功和完全的失敗。
結論前的一些想法：
我認為沒有人會認為XSLT比模板解析引擎更強大，它是一種功能語言。
雖然它沒有像大多數程序語言那樣被廣泛采用，但它仍然是一種真正用於實際項目的語言，人們可以通過XSLT知識獲得聘用，這對於您現有的員工來說是一種可轉移的技能。
XSLT已經存在了一段時間，實現已經成熟，我確信這是長時間運行的模板引擎（如Velocity）的情況，但較新的引擎可能不那么健壯。
無論您決定使用哪種模板語言，它都不太可能像XSLT那樣有詳細記錄。 查看Michael Kay Programmer的任何參考系列，了解如何制作出色的參考書。
工具支持通常非常好......如果您有預算。 XMLSpy和Stylus Studio過去對我都非常有用。
XSLT不僅很難，更重要的是不同。 大多數人都不是正式接受過函數式編程培訓的計算機科學畢業生。 大多數程序員都會以程序化的方式編寫XSLT，這種方式不會利用語言的任何功能並給您帶來維護問題。
XSLT轉換可能很慢並且可能占用大量內存。 如果您的樣式表具有大型XML輸入，則可能會出現問題。
我喜歡XSLT但是你是否應該使用它歸結為幾點：
你是否致力於XSLT？ 您是否擁有XSLT的內部專業知識？ 你准備好了嗎？
你的數據是用XML嗎？ 它在XML中有意義嗎？ 你是否有內部人員喜歡你的數據足以確保它的結構良好並且總是有適當的架構？
除非這些問題的答案是肯定的並且您有復雜的數據需要復雜的渲染過程，否則我不會考慮使用XSLT ...尤其是如果團隊中沒有經驗的話。 糟糕的XSLT比糟糕的模板更糟糕得多。
但是，它可以以可維護的方式呈現復雜的數據，這對於今天的許多模板引擎來說是不可能的。
采用XSL方式將使您的應用程序面向未來。 這意味着，如果您決定在將來添加更多具有不同布局的模板，您將能夠充分利用這些優勢。 在我當前的項目中，我們保存了所使用的XML（在XMLType或CLOB中）並允許其他應用程序訪問數據和XSL模板以通過Web服務生成文檔。 由於我們決定使用XML / XSL，因此我認為原始設計非常容易實現。
請不要將XML / XSLT用於Web前端。 我在這樣的項目中，這太可怕了。 通常，您必須首先從對象或類似的東西生成XML，這是沒有意義的。 第二點是，有很多優秀的HTML編輯器是免費的，但我沒有找到XSLT。 所以編輯復雜的XSLT並不好玩。 我建議使用HTML模板和通用模板引擎。
XSLT的優點是能夠以其他文檔類型（即pdf）生成輸出，並且現在很可能使用pdf輸出。 XML / XSLT還會從視圖中分離數據。
當我們過去完成XSLT時，它允許擴展我們的產品。 輸出保持不變，只需要更改表示層。 當我們有想要“自定義”UI的客戶端時，這為我們提供了很大的靈活性，因為我們需要做的就是替換XSLT文件。 如果您預見到需要進行大量此類更改，XSLT可能就是您的答案。
但是，如上所述，XSLT語法和函數編程思路可能使得難以有效地生成模板。 我們發現，我們喜歡堅持我們學到的技巧，當我們的客戶請求超出我們已經知道的范圍時，沒有人願意為這張票做志願者。 通常有人最終會想出如何完成這項任務，而且我們的“技巧包”變得越來越大，但找出新事物往往非常麻煩。
如果你沒有預見到改變UI，或者至少沒有改變，那么XSLT可能不值得付出額外的努力。
我知道如果你的數據已經是XML，那么XSL方法會如何方便。
但通常情況並非如此。 它位於數據庫中的某個位置，需要在現場生成或來自某些服務。
從這個源創建XML然后能夠從該XML創建HTML在我看來是沒用的。 我會堅持使用（X）Html模板。
根據您的應用程序，擁有一個XML層然后通過XSLT轉換為XHTML也可以，您可以將簡單的WebServices編寫到XML層 - 允許您的客戶使用您的站點數據...
將XML發送到具有轉換鏈接的瀏覽器（忘記確切的語法...）也需要更少的帶寬，因為XSLT文件將保持不變並且您只需要傳遞它構建的原始XML - 比如使用外部CSS樣式表而不是將樣式屬性添加到標記中;）
我認為您需要檢查數據來源是什么。 正如之前的boris callens所提到的，如果您要從數據庫中提取，則必須首先轉換為XML，然后應用轉換。 如果數據源是RSS等，那么XSLT是一個自然的選擇。
XPATH和XSLT具有很高的學習曲線，功能編程可能令人望而生畏。 在時間緊縮中，這可能不是正確的選擇。
對於前端工作，JSON具有較輕的有效負載，並且很容易受到jQuery和其他Javascript庫的支持。 您可能希望將JSON視為數據協議，因為jQuery庫對開發人員來說更容易訪問，並且使用框架提高工作效率的時間遠遠少於使用XSLT，標記中嵌入的Javascript，可怕的語法以及隨附的所有其他細節。前端有XML / XPATH / XSLT。
把事情簡單化。 這是一個人越來越欣賞的原則。
Velocity或Freemarker非常靈活且功能多樣。 您的代碼庫將清晰，易於理解，並且它將比X怪物運行得更快（更快）。
與HTML相比，如果您需要以任何方式解析和處理模板，則可以使用許多XML工具。 因此，您應該選擇XML以獲得使用XML工具和庫的好處。
但是，也就是說，XHTML可能只是滿足您的需求，因為這樣可以完全支持XML工具和庫，同時仍然是現代Web瀏覽器正確處理的普通HTML。 如果您以后需要對這些進行后處理，您仍然可以將XSLT應用於XHTML數據。
我在以前的項目，金融網站中使用過XML和XSLT，它對我們很有用，但是：
我看到使用XSLT的主要原因是，如果您有多個站點都基於相同的XML，但需要不同的HTML輸出。
XML + XSLT真的很酷。 您可以在將來輸出多種類型的目標格式。 但是我知道XML中的嵌入式HTML。 Firefox XSLT不支持“disable-output-escaping”。 見Bugzilla 。
我們使用XSLT在我們的內容管理系統中生成html，它運行得很好。
一些提示：不要嘗試從一個大毛茸茸的XML一次生成所有頁面，你會瘋了。 使用帶有嵌入標記的HTML模板（帶有樣式，裝飾和基本標記的純文本/ html文件）（例如，<！ - MENU - >，<！ - CONTENT - >），並使用xslt-transformation替換標記適當的數據。
話雖如此，我懷疑你真的需要xslt，如果你只有一個布局，永遠。
交換兩條相同的線時，XSL轉換給出不同的結果
[英]XSL-transformation gives different results when interchange two identical lines
聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.
