<delect id="pthrb"></delect>
<dl id="pthrb"></dl>
<video id="pthrb"></video>
<dl id="pthrb"></dl>
<dl id="pthrb"><output id="pthrb"></output></dl>
<video id="pthrb"><output id="pthrb"></output></video>
<dl id="pthrb"><output id="pthrb"></output></dl>
<dl id="pthrb"></dl>
<video id="pthrb"></video>
<dl id="pthrb"></dl><dl id="pthrb"></dl>
<video id="pthrb"><output id="pthrb"></output></video>
<dl id="pthrb"><output id="pthrb"><font id="pthrb"></font></output></dl>
<dl id="pthrb"><delect id="pthrb"></delect></dl>
<video id="pthrb"></video>
<video id="pthrb"></video>
<video id="pthrb"></video>
<video id="pthrb"><output id="pthrb"></output></video><video id="pthrb"></video>
<video id="pthrb"><output id="pthrb"></output></video>
<video id="pthrb"></video>
<dl id="pthrb"><output id="pthrb"></output></dl>
0510-66899765
您的當前位置:主頁 > 新聞&知識 > drupal技術分享 >

Drupal如何“decouple”(解耦)

TAG標簽: 無錫網站技術
時間:2020-06-29 作者:無錫網站建設/無錫SEO優化 瀏覽次數:

    我是使用drupal的內置模板構建網站,還是使用drupal的解耦 JavaScript 框架相結合的方法構建網站好一點呢?

 

    內容管理創新的步伐一直在加快——這是由于內容管理系統需要支持的頻道數量(web、移動、社交、聊天)以及傳統web頻道需要JavaScript的支持所推動的,因此我們看到了headlessdecoupled架構的出現。

 

    已經從社區的各個角落采用了解耦drupal,為了應對解耦的趨勢,我在2016年至2018年分別為架構師和開發人員撰寫了如何解耦drupal的博文。在我上一篇文章的這段時間里,周圍的環境發生了變化,drupal的web服務變得更好了,新的范例——靜態站點生成器和JAMstack正在出現。

 

    該更新我2019年的建議了,就如我去年所做的事情一樣,讓我們從2019年的流程圖開始吧?。ㄟ€有一個用文字描述的可訪問的流程圖)

 

how-to-decouple-drupal-in-2019-flowchart-full.png


    Drupal解耦的不同方法

 

    我想重新討論一些已經建立的Drupal解耦方法,并討論正在被越來越多的人采用的新模式。正如我以前所寫的,從解耦的角度來看Drupal體系結構的三種常見的方法是傳統的(或耦合的)、逐步解耦的和完全解耦的。由于首選項和需求的不同,Drupal存在不同的解耦風格。

 

    在傳統Drupal中,Drupal通常的所有職責都保持不變,因為Drupal是一個整體系統,因此對表示層和數據層保持完全的控制。對于需要完全控制頁面上的視覺元素,并訪問就地編輯和布局管理等功能的編輯人員來說,傳統Drupal仍然是一個很好的選擇。我們一直都知道Drupal。所以大多數新的內容管理項目仍然是這樣構建的。

 

    有時候,JavaScript需要提供高度交互的用戶體驗。在這種情況下,需要一種解耦的方法。在逐步解耦的Drupal中,JavaScript框架是在現有Drupal前端之上進行分層的。這個JavaScript可能只負責在頁面上呈現單個塊或組件,也可能只負責呈現頁面主體中的所有內容。專用于JavaScript的頁面越少,編輯器就越能通過Drupal的管理功能控制頁面。

 

    到今年為止,完全解耦Drupal是一種單獨的解耦Drupal體系結構類別,它反映了表示層和CMS所有方面之間的完全分離。在這個場景中,CMS成為數據提供者,帶有服務器端呈現的JavaScript應用程序負責所有呈現和標記,并通過web服務api與Drupal通信。雖然像就地編輯布局管理這樣的關鍵功能是不可用的,但是完全解耦的Drupal對于那些想要更好地控制前端,并且已經在Angular、React和Vue等框架中構建了應用程序的開發人員很有吸引力。

 

    在過去的一年中,由于JavaScript開發的復雜性不斷增加,完全解耦的Drupal已經發展成兩種不同的模式。所謂的JAMstack (JavaScript,API,Markup)引入了一種新方法:完全解耦靜態站點。靜態站點提高了開發人員的效率性、安全性并降低了復雜性。像Gatsby這樣的靜態站點生成器將從Drupal檢索內容,生成靜態站點,通常通過專門的云提供商(如Netlify)將該靜態站點部署到CDN上。


    你打算建造什么?

how-to-decouple-drupal-in-2019-flowchart-top-section.png 

 

    和往常一樣,關鍵的問題是您試圖構建什么。以下是建筑師在2019年探索解耦Drupal的新建議:

    1. 如果您打算構建一個獨立的網站或web應用程序,那么選擇非耦合Drupal可能是正確的選擇,也可能不是,這取決于開發人員和編輯人員的評估。
 

    2. 如果您的目的是構建多個web體驗(網站或web應用程序),那么您可以使用一個解耦的Drupal實例(沒有自己面向公共前端的內容存儲庫),或者(同時作為內容存儲庫的傳統網站)。根據應用程序的動態性,您可以為高度交互的應用程序選擇JavaScript框架,也可以為大多數靜態網站選擇靜態站點生成器。
 

    3. 如果您的意圖是構建多個非web體驗(本機移動或物聯網應用程序),那么您可以利用解耦的Drupal來公開web服務api,并將Drupal站點作為內容存儲庫使用,而不需要它自己面向公共的前端。

 

    Drupal之所以如此強大,是因為它支持用例廣泛。以及公認的標準,如JSON:API、GraphQL、OpenAPI和CouchDB等, 在drupal中,構建解耦Drupal變得非常簡單。您的技術需求將決定是否將解耦的Drupal作為您的下一個體系結構。

 

    除了技術要求之外,組織因素也經常發揮作用。例如,如果事實證明很難找到具有Twig知識的、優秀的前端Drupal開發人員,那么雇傭更便宜的JavaScript開發人員并實現完全解耦可能更有意義。

 

    什么東西是不能沒有的?

 

how-to-decouple-drupal-in-2019-flowchart-middle-section.png 

    正如我去年所寫的,在對Drupal進行解耦時,任何決策中重要的方面都是項目所需的特性列表;編輯人員和開發人員的需求必須仔細考慮。在你的評估過程中,權衡不同的優點和缺點是關鍵的一步。每個項目都應該對其組織范圍內的需求進行清晰的評估。

 

    許多編輯和營銷團隊選擇特定的CMS是因為它的布局功能和豐富的編輯功能。例如,Drupal允許編輯人員在瀏覽器中構建布局,并將組件拖放到瀏覽器中,而不需要開發人員來完成這些工作。盡管可以在客戶端上重新構建CMS中可用的許多特性,但這可能是一個耗時且昂貴的過程。

 

    近年來,開發人員的經驗也成為一個重要的考慮因素,但不是以我們可能期望的方式。盡管JavaScript環境中的許多變化是開發人員更喜歡非耦合Drupal的動機之一,但現在有多種方法為Drupal編寫前端,這使得人們更容易找到從事非耦合Drupal項目的人。例如,許多組織發現很難找到有Twig經驗的、優秀的前端Drupal開發人員。轉向javascript的前端可以解決其中一些資源挑戰。

 

    開發人員優先處理的需求,和編輯優先處理的需求,之間的平衡將指導您找到滿足您需求的正確方法。如果您所在的組織主要是編輯組織,那么解耦Drupal可能會有問題,因為它減少了編輯可視化的控制。同樣,如果您是擁有更多開發人員的組織機構,那么完全解耦的Drupal會加速開發的進度,同時關鍵的編輯功能消失了。

 


    要考慮當前和未來的趨勢

 

how-to-decouple-drupal-in-2019-spectrum-diagram.png 

    在過去的一年中,JavaScript框架變得越來越復雜,而靜態站點生成器變得不那么復雜。

 

    我聽到的關于JavaScript的一個常見抱怨是,由于復雜性的增加,導致了碎片化的顯示以及缺乏凝聚力。而這也是靜態站點的動力。兩年前,大多數JavaScript開發人員會選擇Angular或Ember這樣的全功能框架來創建簡單的網站,而現在他們可能會選擇靜態的網站生成器。靜態站點生成器仍然允許他們使用JavaScript,但它更簡單,因為性能考慮和構建過程被轉移到托管服務,而不是開發人員的責任。

 

    我預計靜態站點生成器將在未來一年獲得發展勢頭,因為它們提供了積極的開發經驗。靜態站點生成器也吸引了經驗豐富和經驗不足的開發人員。

 

    結論

 

    Drupal仍然是解耦CMS體系結構的理想選擇,而且它只會越來越好。API優先項目在準備JSON:API模塊以便將其包含到Drupal核心方面取得了良好的進展,管理UI和JavaScript現代化項目正在使用一個重新設計的管理界面來改進Drupal的web服務。Drupal對GraphQL的支持不斷改進,現在甚至有一本關于Drupal解耦主題的書。很明顯,今天的開發人員有很多方法可以使用Drupal為解耦架構提供豐富的特性。

 

    隨著將完全解耦的靜態站點作為開發人員可以選擇的另一種體系結構范例的引入,體系結構的可能性比以前更加廣泛。這意味著我去年定義的解耦Drupal方法的范圍變得更加廣泛。這種靈活性繼續將Drupal定義為一種優秀的CMS,適用于傳統方法和解耦方法,其特性遠遠超出Drupal的競爭對手,包括WordPress、Sitecore和Adobe。無論您的團隊組成如何,也不管您的組織需要什么,Drupal都為您提供了解決方案。

 

    特別感謝Preston So和Angie Byron、Chris、Gabe sullivan、Lauri Eskola、Ted Bowman和Wim Leers在撰寫過程中提供的反饋。

 

    可訪問的流程圖

 

    這是本文前面的流程圖圖像的可訪問和描述版本。首先,讓我們列出可用的架構選擇:

    1. 耦合的。在不使用JavaScript的情況下使用Drupal(并將其作為其他使用者的內容存儲庫)。

    2. 逐步分離。使用Drupal進行初始呈現,頂部是JavaScript(并作為其他使用者的內容存儲庫)。

    3. 完全解耦的靜態站點。使用Drupal作為靜態站點生成器的數據源,如果需要,還可以部署到JAMstack托管平臺。

    4. 完全解耦的應用程序。Drupal用作其他用戶訪問的內容存儲庫(如果是JavaScript,則使用Node)。用于服務器端呈現的js)。


    其次,問一個問題“你打算建立什么?”并在“一次經歷”或“多次經歷”中選擇答案。

    如果您正在構建一種體驗,可以問“它是網站還是web應用程序?”,并在“是,單個網站還是web應用程序”或“不是,Drupal僅作為非web應用程序的存儲庫”中進行選擇。

    如果您正在構建多種體驗,可以問“它是網站還是web應用程序?”,回答“是,Drupal作為網站和存儲庫”或“不是,Drupal僅作為非web應用程序的存儲庫”。

    如果您對上一個問題的回答是“否”,那么您應該構建一個完全解耦的應用程序,您的決策就完成了。如果您對上一個問題的回答是“是”,那么可以思考“項目中是否存在一些不可或缺的東西?”

 

    編輯和開發人員的需求都是項目不可或缺的,下面是關于您的項目的一些問題:

 

    編輯需求

 

    1. 編輯是否需要在沒有開發人員的情況下操縱頁面內容和布局?

    2. 編輯需要內置工具,比如就地編輯,背景鏈接工具欄嗎?

    3. 編輯需要在沒有自定義開發的情況下預覽未發布的內容嗎?

    4. 編輯器需要像Drupal的HTML那樣默認訪問內容嗎?

 

    開發者需求

 

    1. 開發人員需要控制可視化而不是編輯?

    2. 開發人員是否需要服務器端呈現Node.js構建功能?

    3. 開發人員需要來自api的JSON并為前端編寫JavaScript嗎?

    4. 開發人員需要的是公開且無法訪問的CMS數據安全性嗎?

 

    如果,在問了所有這些關于您的項目不能沒有的東西的問題之后,您的回答表明您的需求反映了編輯和開發人員的混合需求,那么您應該考慮一個逐漸解耦的實現,您的決策就完成了。

 

    如果您對項目中不能缺少的內容的回答表明您的需求完全反映了開發人員的需求,那么您可以詢問“它是靜態的網站還是動態的web應用程序?”并在“靜態”或“動態”的答案中進行選擇。如果您對上一個問題的回答是“靜態的”,那么您應該構建一個完全解耦的靜態站點,您的決策就完成了。如果您對上一個問題的回答是“動態的”,那么您應該構建一個完全解耦的應用程序,您的決策就完成了。

 

    如果你對項目中不能缺少的東西的回答表明你的需求反映了純粹的編輯需求,那么問兩個問題。問第一個問題,“頁面的某些部分需要javascript驅動的交互嗎?”如果您對第一個問題的回答是“是”,那么您應該考慮一個逐步解耦的實現,您的決策就完成了。如果您對第一個問題的回答是“不”,那么您應該構建一個耦合Drupal站點,您的決策也完成了。

 

    然后,問第二個問題,“您是否需要通過API訪問多個數據源?” 并選擇“是”或“否”的答案 如果您對第二個問題的答案是“是”,那么您應該考慮逐步解耦的實施,并且您的決策已經完成。如果你對第二個問題的答案是“否”,那么你應該建立一個耦合的 Drupal站點,你的決策也完成了。

本站部分信息來源于網絡,僅供個人研究、交流學習使用 如有侵權請告知刪除。

版權聲明:本站部分內容來源于互聯網 如有侵權聯系刪除

Copyright © 無錫眾鼎軟件科技有限公司 版權所有 ??蘇ICP備10220599號-10 ??免責聲明??網站地圖

本站關鍵詞:無錫網站建設,無錫網站制作,無錫網站優化,無錫網絡公司

關于【廣告法】【極限詞】【違禁詞】聲明:請各位職業舉報人高抬貴手繞行本站或發現問題請直接與我們聯系。本公司積極響應廣告法的規定,已經全面盤查網站的【極限詞】【違禁詞】,但因網站內容繁多加之人員排查力度有限,可能造成網頁部分地方仍存在遺漏【極限詞】【違禁詞】的現象,從現在開始本公司宣傳網頁存在的所有廣告法【極限詞】【違禁詞】全部作廢失效,本公司也不承擔此類問題產生的投訴理賠。懇請各位職業舉報人高抬貴手繞行本站或發現問題請直接與我們聯系,如直接投訴就以本說明為準處理!
性高爱潮免费高清视频
<delect id="pthrb"></delect>
<dl id="pthrb"></dl>
<video id="pthrb"></video>
<dl id="pthrb"></dl>
<dl id="pthrb"><output id="pthrb"></output></dl>
<video id="pthrb"><output id="pthrb"></output></video>
<dl id="pthrb"><output id="pthrb"></output></dl>
<dl id="pthrb"></dl>
<video id="pthrb"></video>
<dl id="pthrb"></dl><dl id="pthrb"></dl>
<video id="pthrb"><output id="pthrb"></output></video>
<dl id="pthrb"><output id="pthrb"><font id="pthrb"></font></output></dl>
<dl id="pthrb"><delect id="pthrb"></delect></dl>
<video id="pthrb"></video>
<video id="pthrb"></video>
<video id="pthrb"></video>
<video id="pthrb"><output id="pthrb"></output></video><video id="pthrb"></video>
<video id="pthrb"><output id="pthrb"></output></video>
<video id="pthrb"></video>
<dl id="pthrb"><output id="pthrb"></output></dl>