Мне была предоставлена новая задача от клиента, которая в основном создает CMS для актеров / исполнителей и т. П., Которые клиент будет продавать им.
Он будет в основном быть пакетом и будет работать из коробки в значительной степени похожей на WordPress, вы просто передаете тому, кто ее покупает, но, конечно, это не будет платформой для ведения блога. Это позволит разработчикам:
Я думал, что Observer Patten может быть полезен, но я не уверен в этом. Что вы, ребята, могли бы предложить создать такую гибкую / расширяемую CMS с точки зрения:
Спасибо за ваши идеи и помощь.
Замечательный наблюдатель, но вам придется подумать о том, чтобы выйти за рамки основного шаблона. Канонический шаблон Observer / Subject отправляет объект Subject только наблюдателю, ничего другого, даже не потому, что он уведомляется.
Первоначально решение может показаться, например, также причиной уведомления Наблюдателя, но тогда вы можете в конечном итоге уведомить Наблюдателей, которые не заботятся о некоторых уведомлениях. Лучшему решению может потребоваться, чтобы Наблюдатели также запрашивали список уведомлений, которые они хотели бы получить.
Но это также представляет проблему. Чтобы Наблюдатели фактически привязывались к Субъектам, они должны быть созданы. Каждый раз. Даже если они никогда не понадобятся. Это глупо .
Итак, мы быстро достигли одной из канонических реализаций PHP плагинов: «hooks». Крюки используют ту же концепцию, что и Observer / Subject, но реализация отличается очень важным образом: фактические наблюдатели не создаются для наблюдения за субъектами. Вместо этого Субъекты отправляют уведомление в несколько различных центральных репозиториев. Этот репозиторий настроен со списком всех установленных и активированных плагинов (наблюдателей) и содержит список всех событий, которые каждый плагин хочет получить. Каждый плагин и уведомляется только о том, когда происходит событие, часто с помощью статического метода, а не путем создания экземпляра плагина и уведомления об этом. call_user_func_array и хороший автозагрузчик делает это невероятно тривиально.
Поэтому вы можете создать простой интерфейс для всех плагинов. Необходимые методы включают, но не ограничиваются:
В зависимости от того, насколько вы используете концепцию плагина, вы можете получить плагины, которые имеют настраиваемые пользователем параметры. Возможно, вам стоит принять это во внимание. Вниз по этой дороге находятся системы безумия и конфигурации.
Чтобы сделать плагины эффективными, вам понадобится повесить крючки и часто работать с конечными пользователями, чтобы добавлять новые крючки там, где они нужны.
Виджеты могут легко работать аналогичным образом, как плагины, которые вызываются до рендеринга страницы.
Темы / шаблоны, о мой. У вас, вероятно, есть два больших варианта.
Это решение будет зависеть от ваших конечных пользователей. Smarty невероятно ограничивает, но если вы хотите убедиться, что в шаблоне работает только одобренный код, это может быть жизнеспособным вариантом. Кроме того, небезопасно разрешать редактирование шаблонов Smarty прямо в самом приложении.
С другой стороны, одна из причин, почему шаблоны WordPress работают так хорошо, это то, что они являются чистым PHP. Они могут вызывать любой метод, открытый в WordPress API, и даже делать свою собственную интересную логику. Если вы ожидаете, что ваши конечные пользователи будут технически настроены или, по крайней мере, технически компетентны, то шаблоны PHP – это путь. С другой стороны, разрешение редактирования шаблонов PHP в приложении может открыть огромное потенциальное отверстие безопасности, если вредоносный пользователь попадет в биты администратора. Вероятно, вы хотите ограничить редактирование файловой системы.
Хотя это охватывает создание HTML, вы также должны учитывать CSS. Смогут ли ваши конечные пользователи напрямую манипулировать CSS? Они захотят? Если ваши шаблоны по умолчанию включают в себя достаточно семантических классов, они могут, вероятно, сделать много стилей с небольшими усилиями, если они знают, что они делают. С другой стороны, ваши конечные пользователи могут не знать, что такое CSS, поэтому они могут захотеть, например, выбрать цвет и предустановленные цветовые схемы, а также выбрать схему цветовой схемы и другие подобные неприятные вещи для сборки. Вероятно, лучше подумать об этих ужасах.
Разное.
Никакая CMS не будет полной без концепции проектов и публикаций. У меня нет никаких советов для вас здесь, кроме кода в первую очередь . Если вашему клиенту или конечным пользователям требуется какой-либо исторический архивирование, механизм одобрения руководства или что-либо еще, что делает черновик / публикацию всего, кроме простого поля состояния, вам нужно знать очень скоро. (Я был ужасно укушен этим. Мы разработали всю систему вокруг простой опубликованной / не опубликованной модели и получили около 9/10-х годов за счет создания спецификации и соответствующего кода прототипа, когда поняли, что это не сработает и мы должны были бы сделать что-то гораздо более сложное, чтобы соответствовать требованиям клиентов. Восстановление грубого плана было самым большим временем, с которым мы столкнулись до сих пор.)
Будете ли вы использовать ORM? Если нет, обязательно используйте соответствующую библиотеку интерфейса базы данных. PDO или, возможно, что-то из PEAR или, возможно, Zend_Db. У вас неизбежно будет клиент, который будет настаивать на том, что код работает на Oracle или MSSQL. Или SQLite. Приятно сказать им, что это можно сделать (с некоторыми усилиями). Авторы плагинов также будут благодарны вам за здравомыслие. Не сворачивайте себя.
(Опять же, с вашим уровнем репутации, я ожидаю, что вы уже знакомы со всем, что я сказал. Ах, что я делаю, чтобы отвлечь себя, думая о моем собственном наборе проблем с кодированием …)