Данные запроса и 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), то тогда в каждом из них придётся переклеивать эту строку, что неудобно.Жаль что нет исходного кода для каждого урока
исходный код доступен на github
Или войти через: