Это достаточно «классическая» задача в PHP — приём и отправка обычной формы. Давным-давно, ещё во времена PHP 4, в книгах приводился пример того как это делать. Это всегда был один php-файл, где размещался и обработчик формы, и html-код вывода формы, и вывод ошибок. Понятно, что на заре рождения PHP, говорить о каком-то разделении кода или даже о культуре программирования не приходится. Но, недавно я случайно наткнулся на книгу о PHP 7 2018 года выпуска, где рассказывается об основах языка, классах, есть даже глава о PostgreSQL и даже описано несколько ООП-шаблонов проектирования.

Я с удивлением обнаружил, что до сих пор приводится код из PHP 4, как будто бы последних 20 лет развития PHP-программирования и не было. Сами посмотрите: это я сохранил скриншот. То есть вместо того, чтобы учить студентов нормальным практикам, до сих пор предлагается код 20-летней давности.

Чтобы продолжить, давайте определимся что именно неверно в таком подходе.

Читать дальше...

Думаю, что каждый php-программист знаком с сессиями и может даже работал с ними. Сессии — это стандартный механизм PHP и применяется наверное во всех CMS или фреймворках в том или ином виде. Так же написаны сотни (если не больше) php-библиотек, которые предлагают множество функций для упрощения кода.

В целом же работа с сессиями очень простая и если говорить с практической точки зрения, то есть очень мало задач, которые стоят перед программистом. Первая — это добавление и получение данных в сессию, и вторая — организация flash-сессий для создания «мигающих сообщений». Очень часто это так и называется «flash message». Простой пример: после обновления данных, нужно вывести сообщение для пользователя только один раз.

Читать дальше...

REST — это концепция для взаимодействия компонентов основанный на протоколе HTTP. Не хочу останавливаться на скучной теории (вики в помощь), а дам простое объяснение применительно к сайтам.

В Сети обмен происходит по протоколу HTTP: запрос - ответ. Для того, чтобы передать какие-то данные, их нужно как-то идентифицировать, то есть указать их «признак», «действие» или что-то подобное. И поэтому раньше данные требовалось оформить в виде какого-то сложного формата, обычно это XML или Json.

Так вот, REST говорит что этого делать не нужно. Данные передаём как есть, только у HTTP-запроса указывается метод (параметр) для этих данных. Обычно мы оперируем GET и POST, поскольку они работают «из коробки» в HTML и их поддерживает любой браузер. Но на самом деле, метод у HTTP может быть абсолютно любым. Есть некие общепринятые: PUT, DELETE, OPTIONS, PATCH, но это совсем не стандарт.

Читать дальше...

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

Данный подход делает php-разработки сложными и запутанными. PHP — такой язык программирования, который позволяет решать задачи просто и понятно. Во многих случаях не нужна лишняя обвеска и дополнительный уровень абстракции, которая только запутывает код. Работа с HTTP по какой-то мистической причине, часто обвешивается тонной абстракций, хотя всё крутится вокруг простых вещей.

Читать дальше...

Фактически любой php-проект содержит какой-то роутинг. Без роутинга могут обходиться наверное только единичные страницы, где используется индексный файл index.php (например — лендинг), а также прямое обращение к php-файлу на сервере (сайт/contact.php и т.п.). Также встречаются разработки (обычно старые), где роутинг вынесен в .htaccess, в котором явно прописывается соответствие входящего URL какому-то php-файлу на сервере.

Но на сегодняшний день фактически стандартом стал подход, когда в .htaccess задаются простые правила, по которым все входящие запросы передаются во фронт-контролер (обычно это index.php). После этого загружается «ядро», может быть происходит какая-то инициализация, и дальше управление передаётся в роутер. Роутер на основе заданных правил подключает нужные файлы и, например, запускает на выполнение соответствующие функции/методы. Если бы мы рассматривали минимальное php-приложение (по современным подходам), то оно бы состояло только из фронт-контролера и роутера. Всё остальное — это обвеска на роутер. Именно так устроены современные php-фреймворки.

Читать дальше...

Кэширование — это один из способов ускорить ваш код. Смысл любого кэширования состоит в том, чтобы организовать некий буфер, в котором будет храниться уже готовый результат выполнения: то есть вместо выполнения кода, будет отданы данные из кэша.

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

Совершенно бессмысленно создавать кэш для функций, которые редко вызываются в коде. В этом случае затраты на кэширование просто не «окупаются».

Существует два основных подхода к организации кэша: в файле и в памяти.

Читать дальше...

PHP Standards Recommendations — это набор рекомендаций для разработчиков на PHP. Отношение к PSR разное: от полного неприятия, то фанатичной преданности. Сам по себе PSR появился как копирование Java Community Process (ага, опять Java!). Основное назначение PSR в том, чтобы предоставить PHP-разработчикам некие общие концепции, которые уже были проверены и отработаны.

На сегодняшний день существует 20 рекомендаций PSR. Часть из них находится в активном статусе, другие в виде черновиков. Есть «заброшенные» и отмененные рекомендации. В общем «движуха» достаточно активная. Попробуем во всём этом разобраться.

Читать дальше...