ZoomX.

Пришлось изменить плагин, чтобы решить проблему инвалидации кэша. Получается странно - кэш контекста загружает новый плагин, а в кэше плагинов лежит старый. Решить проблему с помощью резолверов не получилось - до них очередь просто не доходит. В следующей версии ZoomX новый плагин должен заработать. Надеюсь. В общем, новая версия доступна в магазине. Пробуйте.

ZoomX.

Количество пользователей компонента потихоньку растёт. Соответственно, поступают различные предложения по доработке и расширению функционала. А также находятся ошибки, которые я упустил. В новой версии исправлены 4 баги. Спасибо!

[ZoomX]
Вышла новая версия. Кроме багфиксов в ней появилась возможность указывать пользовательский каталог для конфигов компонента для роутов, файловых элементов и исключений. Раньше они хранились в модыксовской /core/config/.

В выходные планирую написать статью про кэширование. Не все понимают как оно работает.

[ZoomX]
Как и обещал, написал статью с разбором механизма кэширования элементов.

https://modzone.ru/blog/2022/04/17/caching-elements-in-zoomx/

Кому интересно узнать, какой шаблонизатор быстрее (стандартный, Fenom или Smarty), читаем статью https://modx.pro/development/22872

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

https://modzone.ru/blog/2022/04/30/pdotools-%D0%BB%D0%B0%D0%B9%D1%84%D1%85%D0%B0%D0%BA-%D0%B4%D0%BB%D1%8F-%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2%D1%8B%D1%85-%D1%81%D0%BD%D0%B8%D0%BF%D0%BF%D0%B5%D1%82%D0%BE%D0%B2/

Fenom значительно превосходит стандартный парсер MODX. Но всегда ли это превосходство бесспорно?

https://modzone.ru/blog/2022/05/01/fenom-vs-modx-tags/

Обновился pdoTools для MODX3. Исправлены почти все баги с гитхаба. Коих было не особо много. Поэтому я перевёл релиз в стабильную версию.

Поговорим о времени

В комментариях к этому посту было несколько просьб подробнее рассказать о часовых поясах. В этом посте я постарался собрать несколько важных тезисов по данной теме.

📚 Теория:

🕔 Всемирное время — UTC. Было введено вместо устаревшего среднего времени по Гринвичу (GMT), поскольку шкала GMT является неравномерной и связана с суточным вращением Земли. Шкала UTC, в свою очередь основана на равномерной шкале атомного времени (TAI).

Часовые пояса вокруг земного шара выражаются как положительное или отрицательное смещение относительно UTC.

❗️ Часовой пояс и смещение — не одно и то же. Почему? Всему виной летнее время (DST — Daylight Saving Time).

👉 Часовой пояс может иметь одно или несколько смещений. Какое именно время принято в качестве стандартного, зависит от текущих политических и/или экономических причин в конкретной стране.

Так как время по UTC не переводится ни зимой, ни летом, то, для тех мест, где есть переход на летнее время и происходит смещение относительно UTC.

⌚️ Unix время — это количество секунд, прошедших с полуночи (00:00:00 UTC) 1 января 1970 года и представлено целым числом.

🔧 Практика:

✅ Следует работать с Unix временем. Такой формат удобно использовать для сравнения и хранения дат. При необходимости его легко преобразовать в любой подходящий формат (и обратно).

На всякий случай упомяну про "критические даты", например 19 января 2038 года в 03:14:08 число секунд достигнет 2^31, что может привести к ошибочной интерпретации этого числа как отрицательного. Возможное решение проблемы состоит в использовании не 32-битной, а 64-битной переменной, которой хватит на 292 млрд лет.

✅ Если вам нужно хранить время только что произошедшего события, текущее время, по факту определённого действия, храните его в UTC (напр. для PostgreSQL —TIMESTAMP WITH TIME ZONE). Это могут быть записи в логах, время регистрации пользователя, совершения заказа или отправки письма.

✅ Нужно ли хранить часовой пояс пользователя?

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

✅ Если время привязано к пользователю — сохраняйте локальное время пользователя и его смещение.

Фактически 1660050128, 2022–09–9T16:02:08+03:00 и 2022–09–9T13:02:08+00:00 — это одно и то же время. Сохраняя смещение мы оставляем важную информацию, которая может оказаться нужной как с точки зрения бизнеса, так и для внутренней отладки, принятия других решений. Иными словами если у вас есть информация, и её хранение вам не доставляет (существенных) дополнительных усилий — не выбрасывайте её. Вы не сможете получить её обратно.

————
🔥 Вот те самые несколько нюансов, которыми хотелось поделиться. Пишите в комментарии, если есть что дополнить, возможно вместе соберём еще несколько дельных советов😉.

#php #datetime #middle

[pdoTools] В новой статье я расскажу про ещё один подводный камень использования шаблонизатора Fenom в MODX, про который знают единицы разработчиков.

https://modzone.ru/blog/2022/08/21/fenom-and-element-parameters/

Law of Demeter (Закон Деметры, LOD)

Этот закон часто используют вместе с темой Tell Don't Ask. Его идея в том, что объект должен обладать ограниченным знанием о других объектах и модулях, взаимодействовать только с теми, кто имеет к нему непосредственное отношение.

Формально правило звучит так, что в клиентском коде вы можете вызывать методы объектов, которые:

✅ Были переданы как аргументы;
✅ Были созданы локально;
✅ Являются глобальными;
✅ Собственные методы;

Пока что непонятно зачем это всё. Давайте разбираться.

Основная задача — создать условия для слабой связанности (loose coupling) между объектами. Но за счёт чего?

🌈 Представьте, вы находитесь в магазине, хотите купить товар стоимостью 25$. Вы дадите продавцу 25$ или вы отдадите продавцу свой кошелек, чтобы тот достал 25$? Давайте разберём этот пример.

👉 В первом случае мы явно знаем, что у объекта SomePerson есть Wallet, который мы хотим получить, чтобы достать (вычесть) из него какую-то сумму денег. Таким образом мы создаём сильную связь (tight coupling) с объектом кошелька, а также раскрываем особенности внутренней реализации.

❓ Чем же лучше второй вариант?

Когда у SomeAnotherPerson мы вызываем метод subtractMoney, это нам даёт дополнительную гибкость, возможность легко изменить внутреннюю реализацию данного метода, не изменяя другие участки кода. Как бонус появляется information hiding, а также это дело менее проблематично мокать в тестах.

🤓 LOD также называют законом "одной точки" (one dot), т.к. ноги растут из Java. В нашем же случае о его применении стоит задуматься при виде более одной стрелочки ->. Обращаю внимание, что речь идёт о методах (или свойствах), которые позволяют получить промежуточный объект, утрируя - о геттерах. То есть две стрелочки в каком нибудь fluent interface (напр. $filter->limit(10)->offset(0)) сюда не относятся.

🙈 У закона Деметры тоже есть свои минусы. Одним из них является необходимость создания большого количества методов-адаптеров. Если вы чувствуете, что классы становятся перегруженными - это признак плохого объектно-ориентированного дизайна.

❓ Можно ли нарушать закон Деметры?

Руководствуйтесь здравым смыслом. Если у вас, например, вложенные DTO, которые предназначены для транспортировки объектов, то нет никакого смысла наворачивать что-то подобное сверху. Используйте только там, где это уместно и помните о преимуществах 😉

#php #oop #middle #source

[ZoomX] Наконец в выходные получилось разобрать бэклог ZoomX и реализовать некоторые задумки. Доработок не очень много, но они важные. Итак, что было сделано:
- Добавлена поддержка контекстов.
- Файловые плагины доступны в контексте mgr.
- Исправлены некоторые ошибки, в том числе ошибка с роутами в пользовательской директории.

Особо хочу обратить внимание, что теперь в роутах все адреса нужно начинать со слеша /, а не только главную страницу. Чтобы не сломать обратную совместимость роуты будут будут работать и без слеша, но для этого задействуется дополнительная обработка, что несет небольшие накладные расходы.

[ZoomX] Новая версия 3.6.0.
Обсудив с товарищами и взвесив все "за" и "против" я решил ни с кем не считаясь добавить возможность формирования $_POST массива для JSON запросов через метод POST. 😁 Нехай будет. Ежели чего, эту фичу можно отключить в настройках. Спасибо за внимание!

Релиз PHP 8.2

Большое обновление языка. Содержит множество новых возможностей, включая readonly-классы, самостоятельные типы null, false и true, устаревшие динамические свойства, улучшение производительности и многое другое.

https://www.php.net/releases/8.2/ru.php

Всем привет!
Обновил pdoTools и для MODX 2.x и для MODX 3. Времени хватило только на исправление критических багов. Исправления коснулись pdoPage:
- Пофиксена XSS уязвимость сниппета pdoPage.
- Допилена поддержка файловых элементов для pdoPage (фикс от создателя pdoTools Василия Наумкина).

На этом всё. Не очень много получилось, но сколько смог.

[pdoTools] Алиасы для элементов
В новой версии pdoTools появится возможность использования алиасов для вызываемых элементов. Они позволяют подменить вызываемый сниппет или чанк на другой элемент или вообще вернуть скалярное значение. Идея родилась в процессе разработки сайта с большим количеством файловых элементов. Согласитесь, гораздо проще запомнить и написать такой вызов

{'test_snippet' | snippet}

чем такой

{'@FILE snippets/folder/test_snippet.php' | snippet}

Такой же подход используется в Laravel например для middleware.

Этот функционал также легко позволяет использовать в качестве модификаторов файловые сниппеты. Указанный модификатор перед вызовом несуществующего сниппета заменяется на файловый.

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

Ну и до кучи решил закинуть все хотелки, о которых писал раньше - это алиасы для файловых элементов и отдельный класс для файловых сниппетов, чтобы избавиться от костыля ввиде создания дополнительного файла с хэшем в виде названия, необходимого для сниппетов из БД. Благодаря отдельному классу пропадает бесючая проблема кэширования, когда правки в файловом сниппете не работают, пока не очистишь кэш.

Как появится свободное время, напишу статью с примерами. В репе править не планирую.