PHP: создание расширяемой [закрытой] системы CMS

Наблюдатель - это хорошо, но вам придется подумать о том, чтобы выйти за рамки базового шаблона. Канонический паттерн Observer/Subject только посылает объект Subject наблюдателю, больше ничего, даже почему его уведомляют.

Изначально решение может показаться таким, как включение причины уведомления Наблюдателю, но тогда вы можете в итоге уведомить Наблюдателей, которым не важны определенные уведомления. Лучшим решением может быть требование, чтобы наблюдатели также запрашивали список уведомлений, которые они хотели бы получать.

Но это также создает проблему. Для того чтобы наблюдатели действительно могли прикрепляться к субъектам, их необходимо инстанцировать. Каждый раз. Даже если они никогда не понадобятся. That's silly.

Итак, мы быстро добрались до одной из канонических реализаций плагинов в PHP: "крючки". Крючки используют ту же концепцию, что и Observer/Subject, но реализация отличается очень важным образом: фактические наблюдатели не инстанцируются для того, чтобы наблюдать за субъектами. Вместо этого Субъекты посылают уведомление в некое центральное хранилище. Это хранилище имеет список всех установленных и активированных плагинов (наблюдателей) и содержит список всех событий, которые каждый плагин хочет получать. Каждый плагин уведомляется только тогда, когда происходит событие, часто через статический метод, а не путем создания экземпляра плагина и его уведомления. call_user_func_array и хороший автозагрузчик делают это невероятно тривиальным.

Поэтому вы можете создать простой интерфейс для реализации всеми плагинами. Методы, которые вам понадобятся, включают, но не ограничиваются:

• Что-то для получения данных о плагине, таких как его название, автор, официальный сайт, версия и т.д. Информация, пригодная для потребления человеком.
• Метод, возвращающий события, на которые плагин хочет подписаться.
• Метод установки, для вещей, которые плагин должен сделать, чтобы установить себя, например, манипуляции с базой данных.
• Метод деинсталляции также может быть полезен.
• Метод (вероятно, статический), который будет получать уведомления о событиях и возвращать необходимые данные.

В зависимости от того, как далеко вы продвинетесь в концепции плагина, вы можете получить плагины с настраиваемыми пользователем параметрами. Возможно, вам придется принять это во внимание. На этом пути лежит безумие и системы конфигурации.

Чтобы сделать плагины эффективными, вам придется разместить крючки везде, и часто работать с конечными пользователями, чтобы добавить новые крючки там, где они необходимы.

Виджеты могут легко работать аналогичным образом, как плагины, которые вызываются перед рендерингом страницы.

Темы/шаблоны, о боже. У вас, вероятно, есть два основных варианта.

1. Smarty, или аналогичный движок шаблонов. Или ваш собственный, не PHP-шаблонный движок.
2. PHP-шаблоны.

Это решение будет определяться вашими конечными пользователями. Smarty невероятно ограничен, но если вы хотите убедиться, что только одобренный код запускается в шаблоне, это может быть приемлемым вариантом. Кроме того, небезопасно разрешать редактирование шаблонов Smarty прямо в самом приложении.

С другой стороны, одна из причин, по которой шаблоны Wordpress работают так хорошо, заключается в том, что они являются чистым PHP. Они могут вызывать любые методы, открытые в API Wordpress, и даже делать свою собственную интересную логику. Если вы ожидаете, что ваши конечные пользователи будут технически грамотными или хотя бы технически подкованными, то PHP-шаблоны - это то, что вам нужно. С другой стороны, разрешение редактировать PHP-шаблоны внутри приложения может открыть огромную потенциальную дыру в безопасности, если злоумышленник проникнет в админку. Скорее всего, вы захотите ограничить редактирование файловой системой.

Хотя это относится к созданию HTML, вы также должны принять во внимание CSS. Смогут ли ваши конечные пользователи работать с CSS напрямую? Захотят ли они этого? Если ваши шаблоны по умолчанию содержат достаточное количество семантических классов, они, вероятно, смогут сделать большое количество стилей без особых усилий, если они знают, что делают. С другой стороны, ваши конечные пользователи могут не знать, что такое CSS, поэтому им могут понадобиться, скажем, подборщики цветов, готовые цветовые схемы, выбор цветовой схемы и другие раздражающие вещи. Возможно, лучше подумать об этих ужасах сейчас.

Разное.

Ни одна CMS не была бы полной без концепции черновиков и состояния публикации. Здесь у меня нет никаких советов, кроме сначала закодируйте это. Если ваш клиент или конечные пользователи хотят какого-либо рода исторического архивирования, механизма утверждения менеджерами или чего-либо еще, что делает черновик/публикацию чем-то иным, кроме простого поля состояния, вы должны узнать об этом очень скоро. (Я был ужасно укушен этим. Мы спроектировали всю систему на основе простой модели "опубликовано/не опубликовано" и прошли примерно 9/10 пути через создание спецификации и соответствующего кода прототипа, когда поняли, что это не сработает, и нам придется сделать что-то гораздо, гораздо более сложное, чтобы удовлетворить требования заказчика. Перестройка чернового плана была самой большой потерей времени, с которой мы столкнулись до сих пор.)

Будете ли вы использовать ORM? Если нет, то обязательно используйте подходящую библиотеку интерфейса базы данных. PDO, или что-то из PEAR, или, может быть, Zend_Db. У вас неизбежно будет клиент, который будет настаивать, чтобы код работал на Oracle или MSSQL. Или SQLite. Будет приятно сказать им, что это можно сделать (с некоторыми усилиями). Авторы плагинов также поблагодарят вас за здравомыслие. Не надо делать свой собственный.

(Опять же, с вашим уровнем репутации, я ожидаю, что вы уже знакомы практически со всем, что я сказал. Ах, что я делаю, чтобы отвлечь себя, думая о своих собственных проблемах кодирования...)