Данные запроса и ServerRequest
В прошлом эпизоде мы поняли, что прямая работа с суперглобальными массивами привязывает нас к конкретному серверу и неудобна при тестировании. Сегодня от этого перейдём к внедрению серверонезависимой структуры ServerRequest. Напишем для неё фабрику и для удобства перейдём на объекты-значения вместо скалярных полей:
- 00:00:30 - Явная передача значений
- 00:02:58 - Особенность работы с телом запроса
- 00:04:51 - Группировка параметров в структуру
- 00:07:12 - Отвязка заголовков от PHP-FPM
- 00:09:19 - Полная информация о запросе
- 00:10:32 - Отдельная структура ServerRequest
- 00:14:09 - Переход к классу
- 00:16:16 - Фабрика по заполнению из глобальных массивов
- 00:17:16 - Тест для класса запроса
- 00:18:00 - Другие HTTP-заголовки
- 00:18:38 - Автосчитывание заголовков
- 00:20:06 - Как протестировать фабрику
- 00:23:45 - Неудобство строковых значений
- 00:25:52 - Объект-значение Uri для адреса
- 00:29:40 - Сложности при проксировании
- 00:32:13 - Экономная обработка файлов
- 00:33:53 - Поток Stream для файлов
- 00:35:27 - Управление курсором при чтении
- 00:41:13 - Обзор результата
Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Спасибо! Ждал продолжения этой серии.
Спасибо!
А зачем мы в классе Uri добавили магический метод для склейки всех фрагментов uri в одно целое, когда, по сути, можем просто обратно отдавать оригинальный uri, который нам пришел в конструкторе?
По логике получается, что нам пришла строка, мы ее разбили на составляющие, а если нам нужно получить оригинальную строку - так можно ее и вернуть, а не склеивать по отдельности. Или не так?
Если у нас в
Uriтолько геттеры, то можно сохранить исходную строку и возвращать её. Но если там появятся модификаторы вроде$uri->setPort(81)или$uri->withPort(81), то тогда в каждом из них придётся переклеивать эту строку, что неудобно.Или войти через: