在過去的五到十年中,為網頁建立網站和應用程式已經變得比人們在 90 年代建立的許多東西複雜得多。使用大寫 HTML、基於表格的佈局和醜陋的 JavaScript 來手動創建網站以在頁面上製作某種類型的可愛動畫已經一去不復返了。
現在,我們擁有各種技術、框架和語言,所有這些技術、框架和語言都可以協同工作,幫助我們建立在瀏覽器中運行的完整軟體應用程式。
這是成為開發人員的美好時光。
由於我們可以使用的技術非常多,樣板檔案變得越來越流行。對於那些不熟悉的人來說,樣板文件基本上是基礎程式碼,可幫助開發人員快速啟動項目,而無需編寫所有網站和/或應用程式通用的程式碼或某些元件。
當然,它們可能會過度到比必要的更笨重和更複雜的程度,但所有好的都是為了奠定基礎- 即提供一種腳手架- 幫助你專注於寫作您的核心算法、代碼和函數對於您的專案和需求來說是獨一無二的。
一年多前,我開始研究兩個專案 - WordPress 外掛程式 Boilerplate 和 WordPress Widget Boilerplate - 每個專案都旨在為開發人員提供使用 WordPress 最佳實踐建立外掛程式的基礎。值得慶幸的是,這些計畫也收到了開源社群的許多其他貢獻,以幫助它們變得盡可能強大。
維護這些項目的一個方面是,我經常收到這樣的問題:為什麼我要這樣安排事情。因此,在這個由兩部分組成的系列中,我們將研究樣板文件、按照我的方式組織它們的原因(和優點),然後我們將使用這些樣板文件之一構建一個簡單的插件,以給出一個範例如何在您未來的專案中使用它們。
建立任何軟體應用程式的關鍵組成部分之一(無論大小)是程式的組織方式。這不僅限於類別和/或函數的關聯方式(這是另一篇文章的主題),還包括文件的組織方式。
理想情況下,檔案不應簡單地轉儲到目錄中,然後留給其他開發人員進行篩選以維護專案。相反,它們應該在邏輯上組織在連貫的目錄中,命名清晰(而不是巧妙),並且應該要求任何為項目做出貢獻的開發人員花費很少的精力來了解某些文件的位置以及將他或她自己的添加內容放在哪裡。
這就像一句古老的格言:
一個放置所有東西的地方,並且所有東西都在它的位置上。
在創建這兩個樣板時,我不僅嘗試遵循這一特定原則,而且還嘗試從 Ruby on Rails 對其佈局進行建模的方式中汲取靈感。具體來說,他們更喜歡「約定優於配置」。
顯然,WordPress 不是 Rails,也不是 MVC 框架,我也不想讓它變成這樣。我只是想從其他開發者那裡借鑒好的想法,以便讓我們的生活在我們的環境中變得更輕鬆。
無論您的外掛有多簡單或多複雜,它都必須至少包含一個 PHP 檔案。 該文件用作核心插件文件,其中包含賦予您的插件生命的所有程式碼、邏輯和功能。
如果您查看各種插件,您會發現開發人員有不同的做法:
我並不是來證明為什麼這些方法(甚至提到的方法)比其他方法更好;只是為什麼樣板以這種方式佈局以及它如何為您工作。
基於 README 檔案的外掛主頁。
除了核心外掛程式檔案之外,WordPress 外掛程式還需要自述文件,以便為最終用戶提供有關如何使用外掛程式以及填充 WordPress 外掛程式儲存庫中的頁面的一些說明。
在最基本的層面上,這就是 WordPress 外掛所需的全部內容:核心外掛程式檔案和自述文件。您只需使用這兩個文件就可以建立一些非常複雜的插件;然而,它可能變得非常難以維護,特別是如果其他開發人員開始貢獻,這最終可能會導致意外的錯誤。
因此,我非常喜歡邏輯上分離程式碼的元件。
視圖是我從 MVC 模式借用的一個字(並且受到 Rails 的啟發)。
視圖可以定義為前端標記,為管理員和網站訪客在螢幕上呈現元素。
僅此而已。很容易,對吧?
當然,因為我們使用 PHP 工作,所以在整個程式碼中肯定會放置一些較小的 PHP 標籤,但視圖檔案的大部分應該是帶有類別和 ID 屬性的 HTML。
在樣板中,有兩個視圖:
當然,外掛可能沒有儀表板或網站訪客的視圖。在這種情況下,views 目錄將被刪除,並且負責將它們包含在核心插件檔案中的程式碼將被刪除。
這是樣板檔案的一個微不足道的元件,因為任何進行任何類型前端開發的人都知道如何管理樣式表,並且可能有自己的組織它們的方法。
但為了保持一致,值得一提的是 css 目錄是保存所有樣式表的位置。這些文件也遵循與其關聯視圖相同的命名約定。
具體:
我曾考慮過為 LESS 或 SASS 引入目錄結構,但我認為這對於開發來說過於固執己見,而且這不是我希望樣板文件發展的方向。我寧願開發者選擇自己的風格並將其融入其中。
為此,我通常在自己的專案中組織樣式表的方式是在css 目錄中引入一個dev 目錄,然後引入一個admin .less 和plugin.less 文件,然後編譯並縮小到根css 目錄中。
這繼續遵循組織樣板的做法,同時也允許我包含我的 LESS 檔案。
與樣式表一樣,JavaScript 檔案是樣板檔案的簡單元件,因為大多數使用 WordPress 並開發主題或外掛程式的人都使用過 JavaScript。
不幸的是,作為使用者和開發人員,在 WordPress 中使用 JavaScript 最令人沮喪的部分之一是開發人員通常不遵循最佳實踐。
一般來說,開發人員應始終執行以下操作:
話雖如此,樣板檔案(如樣式表和視圖)會以下列方式組織:
與樣式表一樣,開發人員也可以選擇在發佈外掛程式之前檢查和/或縮小其 JavaScript。為了避免對JavaScript 檔案的管理方式過於固執,樣板中不包含子目錄,但我經常在js 目錄中建立一個dev 目錄,以便按順序管理我預先檢查、預先縮小的JavaScript。
建立外掛程式的一方面是確保使用其他語言的人可以存取和翻譯它們。為了盡可能簡單,樣板檔案還包含一個 lang 目錄和一個框架 plugin.po 檔案。
此文件旨在與 POEdit 結合使用,以便您完成開發後,可以輕鬆處理所有本地化字串。
除了樣式表和 JavaScript 檔案之外,樣板不提供任何用於管理其他資產(例如圖像)的目錄或約定。
同樣,這是一種平衡,既要努力避免過於固執己見,又要提供足夠的腳手架,讓開發人員開始專注於其核心功能。儘管並非每個插件都包含管理 CSS、JavaScript 或視圖,但它們比包含圖像和其他資源更為常見。
不過,所提供的約定規定您可以建立一個assets目錄、一個images目錄、一個icons目錄,或您將使用的任何其他類型的文件。
WordPress 小部件樣板
那麼這一切有什麼意義呢?打開一個檔案並開始編寫所有程式碼不是很容易嗎?確實。但請記住,大部分開發工作是在產品發布之後進行的,如果您認真對待插件開發,那麼您就從事的是建立產品的業務。
因此,您需要以終為始。使用一致的方案來組織文件、命名文件等:
最重要的是,鷹架應該使開發人員能夠輕鬆地開始處理其產品的核心業務邏輯,而不會妨礙他們。
在本文中,我們回顧了樣板文件組織的“原因”,但我們實際上並沒有回顧樣板文件的“方式”,因此在下一篇文章中我們將僅討論這一點。
具體來說,我們將使用其中一個樣板檔案逐步建立一個插件,以便我們能夠確定取得樣板檔案副本並開始開發所需的典型步驟。
以上是WordPress 樣板在外掛開發中的重要性的詳細內容。更多資訊請關注PHP中文網其他相關文章!