日期:2022-04-14 15:31:17 訪問量:0次
我是使用drupal的內(nèi)置模板構(gòu)建網(wǎng)站,還是使用drupal的解耦與 JavaScript 框架相結(jié)合的方法構(gòu)建網(wǎng)站好一點(diǎn)呢?
內(nèi)容管理創(chuàng)新的步伐一直在加快——這是由于內(nèi)容管理系統(tǒng)需要支持的頻道數(shù)量(web、移動(dòng)、社交、聊天)以及傳統(tǒng)web頻道需要JavaScript的支持所推動(dòng)的,因此我們看到了headless或decoupled架構(gòu)的出現(xiàn)。
已經(jīng)從社區(qū)的各個(gè)角落采用了解耦drupal,為了應(yīng)對(duì)解耦的趨勢,我在2016年至2018年分別為架構(gòu)師和開發(fā)人員撰寫了如何解耦drupal的博文。在我上一篇文章的這段時(shí)間里,周圍的環(huán)境發(fā)生了變化,drupal的web服務(wù)變得更好了,新的范例——靜態(tài)站點(diǎn)生成器和JAMstack正在出現(xiàn)。
該更新我2019年的建議了,就如我去年所做的事情一樣,讓我們從2019年的流程圖開始吧!(還有一個(gè)用文字描述的可訪問的流程圖)
Drupal解耦的不同方法
我想重新討論一些已經(jīng)建立的Drupal解耦方法,并討論正在被越來越多的人采用的新模式。正如我以前所寫的,從解耦的角度來看Drupal體系結(jié)構(gòu)的三種常見的方法是傳統(tǒng)的(或耦合的)、逐步解耦的和完全解耦的。由于需求的不同,Drupal存在不同的解耦風(fēng)格。
在傳統(tǒng)Drupal中,Drupal通常的所有職責(zé)都保持不變,因?yàn)镈rupal是一個(gè)整體系統(tǒng),因此對(duì)表示層和數(shù)據(jù)層保持完全的控制。對(duì)于需要完全控制頁面上的視覺元素,并訪問就地編輯和布局管理等功能的編輯人員來說,傳統(tǒng)Drupal仍然是一個(gè)很好的選擇。我們一直都知道Drupal。所以大多數(shù)新的內(nèi)容管理項(xiàng)目仍然是這樣構(gòu)建的。
有時(shí)候,JavaScript需要提供高度交互的用戶體驗(yàn)。在這種情況下,需要一種解耦的方法。在逐步解耦的Drupal中,JavaScript框架是在現(xiàn)有Drupal前端之上進(jìn)行分層的。這個(gè)JavaScript可能只負(fù)責(zé)在頁面上呈現(xiàn)單個(gè)塊或組件,也可能只負(fù)責(zé)呈現(xiàn)頁面主體中的所有內(nèi)容。專用于JavaScript的頁面越少,編輯器就越能通過Drupal的管理功能控制頁面。
到今年為止,完全解耦Drupal是一種單獨(dú)的解耦Drupal體系結(jié)構(gòu)類別,它反映了表示層和CMS所有方面之間的完全分離。在這個(gè)場景中,CMS成為數(shù)據(jù)提供者,帶有服務(wù)器端呈現(xiàn)的JavaScript應(yīng)用程序負(fù)責(zé)所有呈現(xiàn)和標(biāo)記,并通過web服務(wù)api與Drupal通信。雖然像就地編輯和布局管理這樣的關(guān)鍵功能是不可用的,但是完全解耦的Drupal對(duì)于那些想要更好地控制前端,并且已經(jīng)在Angular、React和Vue等框架中構(gòu)建了應(yīng)用程序的開發(fā)人員很有吸引力。
在過去的一年中,由于JavaScript開發(fā)的復(fù)雜性不斷增加,完全解耦的Drupal已經(jīng)發(fā)展成兩種不同的模式。所謂的JAMstack (JavaScript,API,Markup)引入了一種新方法:完全解耦靜態(tài)站點(diǎn)。靜態(tài)站點(diǎn)提高了開發(fā)人員的效率性、安全性并降低了復(fù)雜性。像Gatsby這樣的靜態(tài)站點(diǎn)生成器將從Drupal檢索內(nèi)容,生成靜態(tài)站點(diǎn),通常通過專門的云提供商(如Netlify)將該靜態(tài)站點(diǎn)部署到CDN上。
你打算建造什么?
和往常一樣,關(guān)鍵的問題是您試圖構(gòu)建什么。以下是建筑師在2019年探索解耦Drupal的新建議:
1. 如果您打算構(gòu)建一個(gè)獨(dú)立的網(wǎng)站或web應(yīng)用程序,那么選擇非耦合Drupal可能是正確的選擇,也可能不是,這取決于開發(fā)人員和編輯人員的評(píng)估。
2. 如果您的目的是構(gòu)建多個(gè)web體驗(yàn)(網(wǎng)站或web應(yīng)用程序),那么您可以使用一個(gè)解耦的Drupal實(shí)例(沒有自己面向公共前端的內(nèi)容存儲(chǔ)庫),或者(同時(shí)作為內(nèi)容存儲(chǔ)庫的傳統(tǒng)網(wǎng)站)。根據(jù)應(yīng)用程序的動(dòng)態(tài)性,您可以為高度交互的應(yīng)用程序選擇JavaScript框架,也可以為大多數(shù)靜態(tài)網(wǎng)站選擇靜態(tài)站點(diǎn)生成器。
3. 如果您的意圖是構(gòu)建多個(gè)非web體驗(yàn)(本機(jī)移動(dòng)或物聯(lián)網(wǎng)應(yīng)用程序),那么您可以利用解耦的Drupal來公開web服務(wù)api,并將Drupal站點(diǎn)作為內(nèi)容存儲(chǔ)庫使用,而不需要它自己面向公共的前端。
Drupal之所以如此強(qiáng)大,是因?yàn)樗С钟美龔V泛。以及公認(rèn)的標(biāo)準(zhǔn),如JSON:API、GraphQL、OpenAPI和CouchDB等, 在drupal中,構(gòu)建解耦Drupal變得非常簡單。您的技術(shù)需求將決定是否將解耦的Drupal作為您的下一個(gè)體系結(jié)構(gòu)。
除了技術(shù)要求之外,組織因素也經(jīng)常發(fā)揮作用。例如,如果事實(shí)證明很難找到具有Twig知識(shí)的、優(yōu)秀的前端Drupal開發(fā)人員,那么雇傭更便宜的JavaScript開發(fā)人員并實(shí)現(xiàn)完全解耦可能更有意義。
什么東西是不能沒有的?
正如我去年所寫的,在對(duì)Drupal進(jìn)行解耦時(shí),任何決策中重要的方面都是項(xiàng)目所需的特性列表;編輯人員和開發(fā)人員的需求必須仔細(xì)考慮。在你的評(píng)估過程中,權(quán)衡不同的優(yōu)點(diǎn)和缺點(diǎn)是關(guān)鍵的一步。每個(gè)項(xiàng)目都應(yīng)該對(duì)其組織范圍內(nèi)的需求進(jìn)行清晰的評(píng)估。
許多編輯和營銷團(tuán)隊(duì)選擇特定的CMS是因?yàn)樗牟季止δ芎拓S富的編輯功能。例如,Drupal允許編輯人員在瀏覽器中構(gòu)建布局,并將組件拖放到瀏覽器中,而不需要開發(fā)人員來完成這些工作。盡管可以在客戶端上重新構(gòu)建CMS中可用的許多特性,但這可能是一個(gè)耗時(shí)且昂貴的過程。
近年來,開發(fā)人員的經(jīng)驗(yàn)也成為一個(gè)重要的考慮因素,但不是以我們可能期望的方式。盡管JavaScript環(huán)境中的許多變化是開發(fā)人員更喜歡非耦合Drupal的動(dòng)機(jī)之一,但現(xiàn)在有多種方法為Drupal編寫前端,這使得人們更容易找到從事非耦合Drupal項(xiàng)目的人。例如,許多組織發(fā)現(xiàn)很難找到有Twig經(jīng)驗(yàn)的、優(yōu)秀的前端Drupal開發(fā)人員。轉(zhuǎn)向javascript的前端可以解決其中一些資源挑戰(zhàn)。
開發(fā)人員優(yōu)先處理的需求,和編輯優(yōu)先處理的需求,之間的平衡將指導(dǎo)您找到滿足您需求的正確方法。如果您所在的組織主要是編輯組織,那么解耦Drupal可能會(huì)有問題,因?yàn)樗鼫p少了編輯可視化的控制。同樣,如果您是擁有更多開發(fā)人員的組織機(jī)構(gòu),那么完全解耦的Drupal會(huì)加速開發(fā)的進(jìn)度,同時(shí)關(guān)鍵的編輯功能消失了。
要考慮當(dāng)前和未來的趨勢
在過去的一年中,JavaScript框架變得越來越復(fù)雜,而靜態(tài)站點(diǎn)生成器變得不那么復(fù)雜。
我聽到的關(guān)于JavaScript的一個(gè)常見抱怨是,由于復(fù)雜性的增加,導(dǎo)致了碎片化的顯示以及缺乏凝聚力。而這也是靜態(tài)站點(diǎn)的動(dòng)力。兩年前,大多數(shù)JavaScript開發(fā)人員會(huì)選擇Angular或Ember這樣的全功能框架來創(chuàng)建簡單的網(wǎng)站,而現(xiàn)在他們可能會(huì)選擇靜態(tài)的網(wǎng)站生成器。靜態(tài)站點(diǎn)生成器仍然允許他們使用JavaScript,但它更簡單,因?yàn)樾阅芸紤]和構(gòu)建過程被轉(zhuǎn)移到托管服務(wù),而不是開發(fā)人員的責(zé)任。
我預(yù)計(jì)靜態(tài)站點(diǎn)生成器將在未來一年獲得發(fā)展勢頭,因?yàn)樗鼈兲峁┝朔e極的開發(fā)經(jīng)驗(yàn)。靜態(tài)站點(diǎn)生成器也吸引了經(jīng)驗(yàn)豐富和經(jīng)驗(yàn)不足的開發(fā)人員。
結(jié)論
Drupal仍然是解耦CMS體系結(jié)構(gòu)的理想選擇,而且它只會(huì)越來越好。API優(yōu)先項(xiàng)目在準(zhǔn)備JSON:API模塊以便將其包含到Drupal核心方面取得了良好的進(jìn)展,管理UI和JavaScript現(xiàn)代化項(xiàng)目正在使用一個(gè)重新設(shè)計(jì)的管理界面來改進(jìn)Drupal的web服務(wù)。Drupal對(duì)GraphQL的支持不斷改進(jìn),現(xiàn)在甚至有一本關(guān)于Drupal解耦主題的書。很明顯,今天的開發(fā)人員有很多方法可以使用Drupal為解耦架構(gòu)提供豐富的特性。
隨著將完全解耦的靜態(tài)站點(diǎn)作為開發(fā)人員可以選擇的另一種體系結(jié)構(gòu)范例的引入,體系結(jié)構(gòu)的可能性比以前更加廣泛。這意味著我去年定義的解耦Drupal方法的范圍變得更加廣泛。這種靈活性繼續(xù)將Drupal定義為一種優(yōu)秀的CMS,適用于傳統(tǒng)方法和解耦方法,其特性遠(yuǎn)遠(yuǎn)超出Drupal的競爭對(duì)手,包括WordPress、Sitecore和Adobe。無論您的團(tuán)隊(duì)組成如何,也不管您的組織需要什么,Drupal都為您提供了解決方案。
特別感謝Preston So和Angie Byron、Chris、Gabe sullivan、Lauri Eskola、Ted Bowman和Wim Leers在撰寫過程中提供的反饋。
可訪問的流程圖
這是本文前面的流程圖圖像的可訪問和描述版本。首先,讓我們列出可用的架構(gòu)選擇:
1. 耦合的。在不使用JavaScript的情況下使用Drupal(并將其作為其他使用者的內(nèi)容存儲(chǔ)庫)。
2. 逐步分離。使用Drupal進(jìn)行初始呈現(xiàn),頂部是JavaScript(并作為其他使用者的內(nèi)容存儲(chǔ)庫)。
3. 完全解耦的靜態(tài)站點(diǎn)。使用Drupal作為靜態(tài)站點(diǎn)生成器的數(shù)據(jù)源,如果需要,還可以部署到JAMstack托管平臺(tái)。
4. 完全解耦的應(yīng)用程序。將Drupal用作其他用戶訪問的內(nèi)容存儲(chǔ)庫(如果是JavaScript,則使用Node)。用于服務(wù)器端呈現(xiàn)的js)。
其次,問一個(gè)問題“你打算建立什么?”并在“一次經(jīng)歷”或“多次經(jīng)歷”中選擇答案。
如果您正在構(gòu)建一種體驗(yàn),可以問“它是網(wǎng)站還是web應(yīng)用程序?”,并在“是,單個(gè)網(wǎng)站還是web應(yīng)用程序”或“不是,Drupal僅作為非web應(yīng)用程序的存儲(chǔ)庫”中進(jìn)行選擇。
如果您正在構(gòu)建多種體驗(yàn),可以問“它是網(wǎng)站還是web應(yīng)用程序?”,回答“是,Drupal作為網(wǎng)站和存儲(chǔ)庫”或“不是,Drupal僅作為非web應(yīng)用程序的存儲(chǔ)庫”。
如果您對(duì)上一個(gè)問題的回答是“否”,那么您應(yīng)該構(gòu)建一個(gè)完全解耦的應(yīng)用程序,您的決策就完成了。如果您對(duì)上一個(gè)問題的回答是“是”,那么可以思考“項(xiàng)目中是否存在一些不可或缺的東西?”
編輯和開發(fā)人員的需求都是項(xiàng)目不可或缺的,下面是關(guān)于您的項(xiàng)目的一些問題:
編輯需求
1. 編輯是否需要在沒有開發(fā)人員的情況下操縱頁面內(nèi)容和布局?
2. 編輯需要內(nèi)置工具,比如就地編輯,背景鏈接工具欄嗎?
3. 編輯需要在沒有自定義開發(fā)的情況下預(yù)覽未發(fā)布的內(nèi)容嗎?
4. 編輯器需要像Drupal的HTML那樣默認(rèn)訪問內(nèi)容嗎?
開發(fā)者需求
1. 開發(fā)人員需要控制可視化而不是編輯?
2. 開發(fā)人員是否需要服務(wù)器端呈現(xiàn)Node.js構(gòu)建功能?
3. 開發(fā)人員需要來自api的JSON并為前端編寫JavaScript嗎?
4. 開發(fā)人員需要的是公開且無法訪問的CMS數(shù)據(jù)安全性嗎?
如果,在問了所有這些關(guān)于您的項(xiàng)目不能沒有的東西的問題之后,您的回答表明您的需求反映了編輯和開發(fā)人員的混合需求,那么您應(yīng)該考慮一個(gè)逐漸解耦的實(shí)現(xiàn),您的決策就完成了。
如果您對(duì)項(xiàng)目中不能缺少的內(nèi)容的回答表明您的需求完全反映了開發(fā)人員的需求,那么您可以詢問“它是靜態(tài)的網(wǎng)站還是動(dòng)態(tài)的web應(yīng)用程序?”并在“靜態(tài)”或“動(dòng)態(tài)”的答案中進(jìn)行選擇。如果您對(duì)上一個(gè)問題的回答是“靜態(tài)的”,那么您應(yīng)該構(gòu)建一個(gè)完全解耦的靜態(tài)站點(diǎn),您的決策就完成了。如果您對(duì)上一個(gè)問題的回答是“動(dòng)態(tài)的”,那么您應(yīng)該構(gòu)建一個(gè)完全解耦的應(yīng)用程序,您的決策就完成了。
如果你對(duì)項(xiàng)目中不能缺少的東西的回答表明你的需求反映了純粹的編輯需求,那么問兩個(gè)問題。問第一個(gè)問題,“頁面的某些部分需要javascript驅(qū)動(dòng)的交互嗎?”如果您對(duì)第一個(gè)問題的回答是“是”,那么您應(yīng)該考慮一個(gè)逐步解耦的實(shí)現(xiàn),您的決策就完成了。如果您對(duì)第一個(gè)問題的回答是“不”,那么您應(yīng)該構(gòu)建一個(gè)耦合Drupal站點(diǎn),您的決策也完成了。
然后,問第二個(gè)問題,“您是否需要通過API訪問多個(gè)數(shù)據(jù)源?” 并選擇“是”或“否”的答案 如果您對(duì)第二個(gè)問題的答案是“是”,那么您應(yīng)該考慮逐步解耦的實(shí)施,并且您的決策已經(jīng)完成。如果你對(duì)第二個(gè)問題的答案是“否”,那么你應(yīng)該建立一個(gè)耦合的 Drupal站點(diǎn),你的決策也完成了。
-
如使用Drupal來靈活地構(gòu)建微站Drupal 8是一個(gè)旨在滿足復(fù)雜內(nèi)容管理需求的Web項(xiàng)目需求的工具。我們聽到了很多關(guān)于headle...
-
對(duì)下一代管理UI的定向反饋Admin UI & JS團(tuán)隊(duì)在 Drupal Europe 會(huì)議上展示了一些很大的進(jìn)步,他們?yōu)镈r...
-
分布式內(nèi)容管理概念解析創(chuàng)建一個(gè)具有多國或者多地區(qū)具有復(fù)雜內(nèi)容的創(chuàng)建和發(fā)布并且可跟蹤的項(xiàng)目,如果沒有一套規(guī)范的內(nèi)容管理系統(tǒng),...