Я пытаюсь создать CMS-подобную систему в PHP. делая его максимально модульным и расширяемым.
Может ли кто-нибудь предложить мне лучший сценарий создания системы event-listener в PHP (например, очень упрощенная версия системы Drupal), создание крючков и их реализация в кратком примере также будет приятным.
Ну, есть три разных способа сделать это с точки зрения реализации (обратите внимание, что это шаблоны проектирования OO, но вы можете реализовать их функционально или процедурно, если хотите).
1. Шаблон наблюдателя
Вы можете реализовать шаблон наблюдателя . В принципе, у вас есть все, что может поднять события. Затем классы / код, который вы хотите прослушать, привязывают к тому, что он хочет прослушать. Итак, скажем, у вас есть контроллер под названием Foo . Если вы хотите прослушать его, вы можете вызвать $fooController->attach($observer); , Затем, когда контроллер хотел что-то сказать, он отправил событие всем наблюдателям.
Это действительно хорошо подходит для системы уведомлений (для расширения классов). Это не так хорошо подходит для изменения поведения кода в реальном времени.
2. Шаблон декоратора. Вы также можете реализовать узор декоратора . В принципе, вы берете объект, который хотите изменить, и «оберните» его в новый объект, который делает то, что вы хотите изменить. Это действительно хорошо подходит для изменения и расширения поведения (поскольку вы можете выборочно переопределять функциональность из завернутого класса).
Это работает очень хорошо, если вы определили интерфейсы и ожидаете, что объекты будут соответствовать им. Если у вас нет интерфейсов (или не используйте их правильно), большая часть того, что может сделать для вас шаблон декоратора, будет потеряна.
Также обратите внимание, что это действительно не способ делать события, это способ изменения поведения объекта.
3. Схема посредника
Вы также можете использовать посредника . В принципе, у вас будет один глобальный посредник, который отслеживает ваших слушателей. Когда вы хотите инициировать событие, вы отправляете событие посреднику. Затем посредник может отслеживать, какие объекты прослушивания хотят получить это событие, и передать сообщение правильно.
Преимуществом этого является то, что он является центральным. Значение нескольких отправителей может отправлять одно и то же событие, а слушателям это не имеет значения, кто его отправил …
Я расширил эту тему в блоге.
Нашел это, очень просто и очень хорошо.
/* Example 1: event::bind('blog.post.create', function($args = array()) { mail('myself@me.com', 'Blog Post Published', $args['name'] . ' has been published'); }); Example 2: event::trigger('blog.post.create', $postInfo); */ class event { public static $events = array(); public static function trigger($event, $args = array()) { if(isset(self::$events[$event])) { foreach(self::$events[$event] as $func) { call_user_func($func, $args); } } } public static function bind($event, Closure $func) { self::$events[$event][] = $func; } }
Так я сделал это в нескольких проектах
Все объекты создаются с помощью функции-конструктора вместо new оператора.
$obj = _new('SomeClass', $x, $y); // instead of $obj = new SomeClass($x, $y);
это имеет много преимуществ по сравнению с исходным new , с точки зрения обработки событий важно, чтобы _new() поддерживал список всех созданных объектов.
Существует также глобальная функция send($message, $params) которая выполняет итерацию, хотя этот список, и, если объект предоставляет метод «on_ $ message», вызывает этот метод, передавая параметры:
function send() { $_ = func_get_args(); $m = "on_" . array_shift($_); foreach($_all_objects as $obj) if(method_exists($obj, $m)) call_user_func_array(array($obj, $m), $_); }
Так, например, send('load') on_load метод on_load для каждого объекта, который он определил.
Если вы используете PHP 5.3 (и, следовательно, имеете доступ к богатым закрытиям), система событий / фильтров в литии – это то, что я буду использовать в качестве основы для проектирования АОП в PHP.
Не уверен, почему люди в PHP думают, что они получают что-то от Listeners. Простой вопрос: если я ищу PHP-разработчиков, я просто задаю один вопрос: каковы проблемы и ограничения MVC?
Если вы не можете ответить на этот вопрос, вы не должны смотреть на внедрение слушателей или, в этом случае, реализацию структуры.
Далее Знай свой язык. PHP – это однопоточный, однострочный. Значение памяти и объектов зависит от потока. В результате слушатели и другие объекты, оставшиеся в живых, в Java / C # никогда не должны использоваться в php, поскольку они, как правило, дорого стоят, чтобы создавать и усложнять приложение, не получая достаточного значения, чтобы оправдать их.
Рамки НЕ поддерживаются, и по состоянию на 2 года назад руководство по PHP заявляло, что они не намерены поддерживать Framework для PHP. Это означает, что для того, чтобы заставить фреймворк работать наполовину так же хорошо, как собственный PHP с PEAR, вам нужно реализовать десятки дополнений, которые занимают память, затрудняют разработку и обфускацию кода без какой-либо выгоды.
Стандартная PHP-разработка быстрее и проще в использовании, чем в большинстве фреймворков для PHP. Существует несколько библиотек PEAR, которые могут помочь вам в вашей задаче. Не пытайтесь быть многопоточным разработчиком в однопоточной системе, это сервер не является реальной стоимостью.
Если вам нужна межпоточная связь, бросьте PHP и развивайтесь на многопоточном языке.
Не используйте технологию из-за слова BUZZ. MVC чрезмерно используется и в 99% случаев используется неправильно. Результат варьируется от медленных систем до плохих структур данных / проверки. Слушатели – то же самое, знаете, что это, прежде чем использовать его.
Первый вопрос перед тем, как я? Должно быть, почему я должен? Знайте свою технологию, тренды учат вредным привычкам и дрянным разработчикам.
Извините, soapbox закончился, просто надоело запускать на работу программистов PHP-разработчиков, которые попугаи консервируют ответы и идеологии, не думая об этом. Вот почему разработчики Java высмеивают разработчиков PHP, потому что они пытаются использовать технологии, на которых их язык не был разработан, и создатель сказал, что он не намерен поддерживать.
Есть отличные разработчики PHP, а не те, кто пытается использовать жесткие рамки, такие как Zend Framework, или такие технологии, как контроллеры домена или прослушиватели.