Поддержка модов без правки кода

[dandandan]

По идее скрипту без разницы сколько модов будут править 1 файл. А вот с порядом правки (какой мод первый, какой второй и т.д. и т.п) - не знаю как это реализовано и реализовано ли.

В моем пример выше создасться результирующий файлик вида

admin_language_russian_russian.php в отдельной папочке, где будут записаны все изменения. И он будет запускаться вместо исходного

 

[Den1xxx]

Для просмотра ссылки Войди или Зарегистрируйся

Мне кажется, это вообще вопрос про шаблон проектирования Observer (Наблюдатель)
Классика кода здесь
Для просмотра ссылки Войди или Зарегистрируйся

 

[Den1xxx]

Кстати, спасибо за поднятую проблему, сам заинтересовался реализацией.
Правда, мне для других целей надо — более удобное проектирование уведомлений, чем есть в своем проекте сейчас.
Наиболее доступно объяснено как работает на русском нашёл здесь.
Для просмотра ссылки Войди или Зарегистрируйся
Приемлимая реализация в 1 файл здесь
Для просмотра ссылки Войди или Зарегистрируйся
Надеюсь, будет полезно.
Надеюсь, если нашли что-то более полезное, сообщите.

 

[Горбушка]

@Den1xxx, эта штука для ООП, меня интересует процедурный стиль.

Обсервер для процедурного не возможен, т.к. нельзя переназначить функцию.
Да и не нравится он мне... Чтобы просто умножить входную цифру в 500-строчную функцию мне придётся её копировать полностью в мод, судя по описанию Вики...

+ Обсервер не даёт возможности многократного изменения функции.

Либо я что-то не так понял

 

[Den1xxx]

@Den1xxx, эта штука для ООП, меня интересует процедурный стиль.

Там во втором примере — функция s(), создает объект типа синглтон.
Ксатати, пример хоть и простой, но работает.
Загрузил на сервер, смотрим:

Спойлер: Выполнение

B loaded!
B was attached.
A loaded!
A found event.one
B found event.one
C found event.one
B was detached.
New DB object created!
Running Query
New DB object created!
Running Query
New DB object created!
Running Query
Running Query
Running Query
Running Query
Done
Memory: 3144
0.000999927520752

Тебе ж не обязательно 100% процедурный? Я понимаю, что хочешь как проще сделать и как писать меньше кода.
Но тут фишка в том, что генерировать функции с одинаковыми именами хрен получится, а вот объекты — сколько угодно.
То есть, чисто функционально — через static массив внутри функции либо объект, либо глобальный массив (это самый плохой подход по нынешним меркам).
Вот тут покопался в записях своих (интересовался этим полгода назад) и нашел ещё круче Для просмотра ссылки Войди или Зарегистрируйся
События с блекджеком и шлюхами емайлом и конфигами.
Вообще просто сам голову ломаю над этим и скорее всего напишу свой код.
Просто пока не дозрел до того, как правильно сделать
Ну а так ты сам нашёл чё-нить? Может, что ценнее, чем я, хехе.

По идее, события должны генерировать действия:
1. Извещения в лс
2. Емайл
3. Выполнение произвольной функции.
Вот 3-й пункт — это то, что тебе надо на этом этапе. Впрочем, пп. 1 и 2 реализуются и через 3, так что если п. 3 оставить — этого м.б. достаточно.
Ну и потом можно ещё там дописывать, например, пуш-уведомления или СМС.

//Upd
См. нашел ещё проще Для просмотра ссылки Войди или Зарегистрируйся

/*
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;
    }
}