Вы все в 1 ветке разрабатываете или просто сейчас нет долгоиграющих фич на github?
Про composer и psr повторятся не буду, все выше было написано (проверку версии php и расширений тоже можно на откуп composer отдать.). События в вашей cms это Trigger или я их не нашел?
Для своих глобальный констант лучше префик завести.
1. Через нижнее подчеркивание обычно защищенные методы класса называют, а не публичные.
2. Для коробочных модулей как-то странно выглядит пункт
И в основном шаблонном представлении добавим {{module.habr }}
3. У вас на View это глобальный модуль, доступный всем частям приложения, именнованные куски тоже доступны всем получается. Все о всех знают, это не есть хорошо.
4. Возьмите за основу Symfony\Component\HttpFoundation. Используйте их request и response. Вместо того, чтобы прямо в коде header писать сразу.
Недавно тоже разбирался с flexbox, переверстал страницу с формой авторизации на сайт. Css код в 2 раза сократился. Далее буду плавно использовать flexbox везде, где не нужен старый ослик.
Пороговый лимитер получается. Почему бы тогда просто не сетить expire первому запросу и писать все в 1 ключ? Получится пороговый лимитер, который отсчет dyration ведет от первого запроса и сам удаляется по expire, но при этом всего 1 ключ.
pipe.incr(key)
pipe.expire(key, duration)
if pipe.execute()[0] > limit:
очень грязно считает время, за счет expire на каждом шаге. В итоге если постоянно понемногу добавлять, то мы все равно наберем limit за счет того, что ключ не выпадет по expire.
Для фиксированного лимитера expire только в момент создания ключа должен создаваться, т.е. если результат инкремента вернет 1. Для плавающего лимитера, нужно учитывать duration для каждого предыдущего запроса, так как для части из них это время уже могло пройти.
Добавьте в свою IDE и описание проекта какой-то формат кодирования кода (PSR-0) и привидите весь код в 1 формат. Там будет проще и вам и участникам проекта.
Главное чтобы себе в кайф все происходило и без напрягов. А то смотришь на некоторых, их как-будто кто-то заставил прийти на хакатон и что-то делать. Ловите кайф :)
Не совсем понял зачем 2 круга обработки событий и как это работает.
Я когда события делал я все события разделил как во многих cms на 3 типа — событие, фильтр, действие (деление очень условное, это все событие). Событие просто кидает сообщение, обработчики его обрабатывают (каждый следующий обработчик получает результат предыдущего). Фильтр дает на вход значение, обработчики его «фильтруют» и возвращают на выходе отфильтрованное значение. Действие, как и событие, кидает событие, но оно ждет что в итоге что-то вернется инициатору события (событие с присвоением).
Уже 4 года все устраивает и еще не было момента, где бы уперся. Для приложение с очень гибкими требованиями событийная модель достаточно неплохо подходит за основу построения архитектуры на мой взгляд.
Про composer и psr повторятся не буду, все выше было написано (проверку версии php и расширений тоже можно на откуп composer отдать.). События в вашей cms это Trigger или я их не нашел?
Для своих глобальный констант лучше префик завести.
Можно ли в современных браузерах добавить/заменить такой глобальный обработчик исключений?
github.com/zenn1989/ffcms/blob/9a08544e34955a420fdb36c9288f7dd74bad1a5e/load.php
2. Для коробочных модулей как-то странно выглядит пункт
3. У вас на View это глобальный модуль, доступный всем частям приложения, именнованные куски тоже доступны всем получается. Все о всех знают, это не есть хорошо.
4. Возьмите за основу Symfony\Component\HttpFoundation. Используйте их request и response. Вместо того, чтобы прямо в коде header писать сразу.
очень грязно считает время, за счет expire на каждом шаге. В итоге если постоянно понемногу добавлять, то мы все равно наберем limit за счет того, что ключ не выпадет по expire.
Для фиксированного лимитера expire только в момент создания ключа должен создаваться, т.е. если результат инкремента вернет 1. Для плавающего лимитера, нужно учитывать duration для каждого предыдущего запроса, так как для части из них это время уже могло пройти.
Я когда события делал я все события разделил как во многих cms на 3 типа — событие, фильтр, действие (деление очень условное, это все событие). Событие просто кидает сообщение, обработчики его обрабатывают (каждый следующий обработчик получает результат предыдущего). Фильтр дает на вход значение, обработчики его «фильтруют» и возвращают на выходе отфильтрованное значение. Действие, как и событие, кидает событие, но оно ждет что в итоге что-то вернется инициатору события (событие с присвоением).
Уже 4 года все устраивает и еще не было момента, где бы уперся. Для приложение с очень гибкими требованиями событийная модель достаточно неплохо подходит за основу построения архитектуры на мой взгляд.