問題描述
客戶給了我一項新任務，主要是為演員/歌手等創建一個 CMS，客戶將向他們出售.
I have been given a new task from the client which is basically creating a CMS for actors/singers and the like that client will be selling out to them.
它基本上是一個軟件包，開箱即用，與 WordPress 非常相似，您只需將其交給購買它的人，當然這不會成為一個博客平臺.它將允許開發人員:
It will basically be a package and would work out-of-box pretty much similar to WordPress, you just hand over to whoever buys it but of course this is not going to be a blogging platform. It will allow developers to:
- 添加插件/小部件
- 添加模板/主題
我認為 觀察者模式 可能有用，但我不太確定.你們可以建議在以下方面創建這種靈活/可擴展的 CMS:
I thought the Observer Pattern may be useful but I am not that sure about it. What you guys could suggest to create such flexible/extensible CMS in terms of:
- 能夠添加插件(例如 WordPress)
- 能夠添加主題/模板(例如 WordPress)
- 設計模式
- 任何其他事情
推薦答案
Observer 很好，但您將不得不考慮超越基本模式.規范的觀察者/主題模式只將主題對象發送給觀察者，沒有別的，甚至沒有為什么通知它.
Observer's fine, but you're going to have to consider going beyond the basic pattern. The canonical Observer/Subject pattern only sends the Subject object to the Observer, nothing else, not even why it's being notified.
最初，解決方案似乎還包括向觀察者發出通知的原因，但隨后您可能最終會通知不關心某些通知的觀察者.更好的解決方案可能是要求觀察者還要求提供他們希望收到的通知列表.
Initially, the solution might seem like also including the reason for the notification to the Observer, but then you might end up notifying Observers that don't care about certain notifications. A better solution might be requiring Observers to also ask for a list of notifications they'd like to receive.
但這也帶來了一個問題.為了讓觀察者真正將自己附加到主題，它們必須被實例化.每一次.即使他們永遠不需要.那是愚蠢的.
But that also presents a problem. In order for the Observers to actually attach themselves to Subjects, they have to be instantiated. Every single time. Even if they'd never be needed. That's silly.
因此，我們很快就達到了插件的規范 PHP 實現之一:hooks".Hooks 使用與 Observer/Subject 相同的概念，但在一個非常重要的方面實現不同:實際的 Observers 不是為了觀察 Subjects 而實例化的.相反，Subjects 向某種中央存儲庫發送通知.該存儲庫配置了所有已安裝和激活插件(觀察者)的列表，并包含每個插件想要接收的所有事件的列表.每個插件僅在事件發生時通知，通常通過靜態方法而不是通過創建插件實例并通知它.call_user_func_array 和一個好的自動加載器使這變得非常簡單.
So, we've quickly reached one of the canonical PHP implementations of plugins: "hooks". Hooks use the same concept as Observer/Subject, but the implementation is different in a very important way: the actual Observers aren't instantiated in order to Observe Subjects. Instead, Subjects send a notification to some variety of central repository. This repository is configured with a list of all installed and activated plugins (Observers), and contains a list of all of the events that each plugin wants to receive. Each plugin and notified only when the event takes place, often through a static method rather than by creating an instance of the plugin and notifying it. call_user_func_array and a good autoloader makes this incredibly trivial.
因此，您可以為所有插件創建一個簡單的接口來實現.您需要的方法包括但不限于:
You can therefore create a simple Interface for all plugins to implement. Methods that you'll need include but are not limited to:
- 用于獲取有關插件數據的內容，例如名稱、作者、官方網站、版本等.人類可使用的信息.
- 返回插件想要訂閱的事件的方法.
- 一種安裝方法，用于插件為了安裝自身而需要做的事情，例如操作數據庫.
- 卸載方法也可能很方便.
- 將接收事件通知并返回所需數據的(可能是靜態的)方法.
根據您采用插件概念的程度，您最終可能會得到具有用戶可配置選項的插件.您可能需要考慮到這一點.沿著這條路走下去的是瘋狂和配置系統.
Depending on how far you take the plugin concept, you could end up with plugins that have user configurable options. You might need to take that into account. Down that road lies madness and configuration systems.
為了使插件有效，您需要到處放置鉤子，并經常與最終用戶合作，在需要的地方添加新的鉤子.
In order to make plugins effective, you're going to need to place hooks everywhere, and frequently work with end-users to add new hooks where they are needed.
小部件可以很容易地以類似的方式工作，就像在頁面呈現之前調用的插件一樣.
Widgets can easily work in a similar way, as plugins that get called prior to page rendering.
主題/模板，天哪.您可能有兩大選擇.
Themes/templates, oh my. You probably have two big options.
- Smarty 或類似的模板引擎.或者您自己的非 PHP 模板引擎.
- PHP 模板.
此決定將由您的最終用戶決定.Smarty 的限制令人難以置信，但如果您想確保模板中只運行經過批準的代碼，它可能是一個可行的選擇.此外，允許直接在應用程序本身中編輯 Smarty 模板并不是不安全的.
This decision will be driven by your end users. Smarty is incredibly limiting, but if you want to make sure that only approved code runs in a template, it might be a viable option. Furthermore, it's not unsafe to allow editing of Smarty templates right in the application itself.
另一方面，Wordpress 模板運行良好的原因之一是它們是純 PHP 的.他們可以調用 Wordpress API 中公開的任何方法，甚至可以執行自己有趣的邏輯.如果您希望您的最終用戶具有技術頭腦，或者至少具有技術能力，那么 PHP 模板就是您的最佳選擇.另一方面，如果惡意用戶進入管理位，允許在應用程序中編輯 PHP 模板可能會打開一個巨大的潛在安全漏洞.您可能想限制對文件系統的編輯.
On the other hand, one of the reason Wordpress templates work so well is that they're pure PHP. They can call any method exposed in the Wordpress API, and even do their own interesting logic. If you expect your end users to be technically minded, or at least technically competent, then PHP templates are the way to go. On the other hand, allowing editing of PHP templates within the application can open up a huge potential security hole if a malicious user gets into the admin bits. You probably want to restrict editing to the filesystem.
雖然這涵蓋了 HTML 創建，但您還應該考慮 CSS.您的最終用戶能否直接操作 CSS?他們愿意嗎?如果您的默認模板包含足夠多的語義類，那么如果他們知道自己在做什么，他們可能會毫不費力地進行大量樣式設置.另一方面，您的最終用戶可能不知道 CSS 是什么，所以他們可能想要，哦，比如說，顏色選擇器和預先構建的配色方案，以及配色方案選擇器，以及其他類似令人討厭的東西來構建.現在最好考慮一下那些恐怖事件.
While this covers HTML creation, you should also take CSS into consideration. Will your end-users be able to manipulate CSS directly? Will they want to? If your default templates include enough semantic classes, they can probably do a great deal of styling with not a lot of effort, if they know what they're doing. On the other hand, your end-users might not know what CSS is, so they might want, oh, say, color pickers and pre-built color schemes, and a color scheme chooser, and other such annoying things to build. It's probably best to think about those horrors now.
雜項.
如果沒有草稿和發布狀態的概念，任何 CMS 都是不完整的.除了先編碼之外，我在這里沒有給你任何建議.如果您的客戶或最終用戶想要任何類型的歷史存檔、管理審批機制或任何其他使草稿/發布的內容不只是簡單狀態字段的內容，您需要很快知道.(我被這個深深地咬住了.我們圍繞一個簡單的已發布/未發布的模型設計了整個系統，并在我們意識到它不起作用時通過規范構建和相關原型代碼獲得了大約 9/10我們必須做一些更遠、更復雜的事情才能真正滿足客戶的要求.重建粗略的計劃是我們迄今為止遇到的最大的一次浪費時間.)
No CMS would be complete without the concept of drafts and publish states. I don't have any advice for you here, other than code this first. If your customer or the end-users want any sort of historical archiving, managerial approval mechanism, or anything else that makes draft/published anything but a simple state field, you need to know very soon. (I've been bitten horribly by this one. We'd designed the entire system around a simple published/not-published model, and got about 9/10ths through spec building and related prototype code when we realized it wouldn't work and we'd have to do something far, far more complex to actually meet customer requirements. Rebuilding the rough plan was the single largest time-sink we encountered so far.)
你會使用 ORM 嗎?如果沒有，請確保使用適當的數據庫接口庫.PDO，或者來自 PEAR 的東西，或者 Zend_Db.您不可避免地會有一個客戶堅持代碼在 Oracle 或 MSSQL 上運行.或 SQLite.很高興告訴他們可以做到(需要付出一些努力).插件作者也會感謝您的理智.不要自己動手.
Will you use an ORM? If not, be sure to use a proper database interface library. PDO, or maybe something from PEAR, or maybe Zend_Db. You'll inevitably have a customer that will insist that the code runs on Oracle or MSSQL. Or SQLite. It'll be nice to tell them it can be done (with some effort). Plugin authors will thank you for the sanity as well. Don't roll your own.
(再說一次，對于您的代表級別，我希望您已經熟悉我所說的幾乎所有內容.啊，我做的事情是在思考自己的編碼問題時分散自己的注意力......)
(Then again, with your rep level, I expect that you're already familiar with pretty much everything I've said. Ah, the things I do to distract myself while thinking about my own set of coding problems...)
這篇關于PHP:創建可擴展的 CMS 系統的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！