Комментарии 29
PSR будет потом?
Опять? ОПЯТЬ! Это не фреймворк, это даже не библиотека, это - HELLO WORLD на PHP!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
думаете уже обогнали по количеству ботов на пайтоне? ))
Вот ниже у вас нормальный разбор. А этот комментарий очень плохой.
Нет абсолютно ничего плохого в статьях про Hello world. Это никак не может быть аргументом против какой-либо статьи. Как раз наоборот — статей начального уровня нужно больше, особенно для языков типа РНР, в котором все статьи начального уровня застряли в 20 веке и там совсем уж хтонический ужас.
Любая технология развивается, развиваются и представления о ней. Поэтому, повторюсь — новые статьи на ту же тему, если они доносят её лучше, нужны и должны приветствоваться. А если есть претензии к качеству материала, то вот их как раз можно и нужно высказывать.
DI будет?
Да очередной Hello, World, но полезный для таких неучей, как я, например.
Реакция "гуру", познавших дзен - весьма странная.
Автор, продолжайте. Вполне интересно.
Вот только Fatal error: Uncaught ArgumentCountError: Too few arguments to function app\core\Application::__construct()
$ROOT_DIR - а- то конструктору не даем нигде.
А что вам мешает посмотреть реализацию популярных мини фреймворков на гитхаб?
Посмотреть ничего не мешает и посмотрю, обязательно. Яж не про реализацию минифреймворков на гитхаб, а про конкретно написанное здесь.
Рекомендую кстати всегда вот этот цикл прочесть. https://symfony.com/doc/current/create_framework/index.html
Дает в целом понимание что и как устроено в больших фреймворках и в частности подводки к архитектуре симофни
Посмотрел на slim. Таже - фигня в плане логики. Нифига мой мозг не принимает подход, в котором мы:
При получении запроса делаем $app->router->get(маршрут, обработчик маршрута ) , то-есть,
Мы при получении запроса СОЗДАЕМ и маршрут и его обработчик.
При этом создаваемый маршрут никоим образом не связан с запросом.
И тут же этот маршрут обрабатываем.
вместо того, чтобы сделать $handlerResult = $app->routeHandler($app->router->get($app->request->getPath());
То-есть вопрос-то не конкретно к приведенному автором примеру, а в принципе почему так? я это к чему, вот есть у меня, например, 50 страниц сайта с единой точкой входа. Моя прямолинейная логика говорит примерно следующее:
мне надо создать массив маршрутов, вида
[
'маршрут1' => Array(параметры маршрута1),
'маршрут2' => Array(параметры маршрута2),
и т.д.
]при получении запроса напрмер localhost:8080/маршрут3, получить путь 'маршрут3' из URI
поискать путь в маршрутах и получить параметры обработки маршрута
обработать маршрут и выдать результат.
То есть по факту 3 вопроса пока по крупному:
Почему маршрут никак очевидным образом не ориентированный на URI СОЗДАЕТСЯ при получении запроса, а не ИЩЕТСЯ на основании URI запроса?
Почему маршрут Создается вместе с обработчиком (что для 50 страниц сайта надо 50 обработчиков/ 50 ссылок на обработчик в маршрутах? А если обработчик "сложносочиненный"? А сложносочиненному обработчику сразу надо дать все данные для обработки - таки их же для начала построить надо из чего-то?)?
Для чего при каждом запросе СОЗДАВАТЬ маршрут заново?
$app->router->get(маршрут, обработчик маршрута )
Это не создание маршрута - это фактически конфигурация приложения. То, что его явно нужно конфигурировать кодом каждый раз - это особенность, но фактически это так или иначе происходит во всех фреймворках, просто условный symfony читает кэш DI\роутинга (или строит его по YAML конфигам) неявно для вас, но он тоже это делает это каждый раз при запуске.
Здесь же вы просто явно выполняете это действие. Для новичков на самом деле эта явность кмк очень полезна.
Если вы будете запускать Slim на каком-нибудь RoadRunner, то вы явно увидете разницу между конфигурированием и запуском. Конфигурирование (get) будет вне цикла воркера, а запуск внутри.
пример:
конфигурация https://github.com/n1215/roadrunner-docker-skeleton/blob/slimphp/app.php
запуск https://github.com/n1215/roadrunner-docker-skeleton/blob/slimphp/worker.php
Вот теперь стало понятнее. с одной стороны. а с другой, появляется глобальный вопрос, для чего так мощно усложнять?.
Почему от этого всего не оставить только :
$request = new Request();
$path = $request->getPath();А дальше примитивная магия:
Это для примераswitch ($path){
case '\':
echo('Hello, World!');
break;
case '\users':
echo('USERS');
break;
case '\users\ivan':
echo('Hello, Ivan');
break;
default:
echo('404');
break;
}Это для примера. а не в качестве настойчивости на своей точке зрения.
Пока вот это даже внешне выглядит сильно симпатичнее и понятнее, чем приведенные примеры конфигурации и запуска суммарно.
Пока для меня примеры выглядят как попытка забить гвоздь перфоратором.
Так в целом можно. Но это будет работать только для достаточно простых кейсов. Давайте я добавлю вам требование:
Для всех роутов с префиксом
\usersтребовать авторизацию.
И все эти сложные конфиги сразу заиграют новыми красками
Но авторизацию-то в обоих случаях придется писать ))) (я не говорю про большие фреймворки, я пока только про мелочевку)
Вопрос именно в том, как вы со switch-case навесите авторизацию на группу роутов. Конечно, если вас устраивает на таких объемах каждый роут описывать полностью вручную (вот этот с авторизацией, этот без, этот html с темплейтом и учетом локалей, этот json сырой, этот такой же как вот этот, только без параметров, вместо них вот такие дефолты и тд), то вам все это не надобно, безусловно. вам вообще в этом случае скорей всего хватит пары-тройки .php файлов с инклудами (это кстати описано в цикле статей, который я линканул выше)
Понятно что не надо забивать гвозди шуруповертом. простые одноразовые задачи можно решать без всего этого.
Вот и я об том, что использовать что-то надо в соответствии с задачей. Не более.
В любом случае, я вопросы спрашиваю больше из энтомологическоо интереса. Вполне понятно, что писать фреймворк самому нет ни желания ни необходимости.
А вот начальное понимание подхода - интересно. вдруг понадобится использовать, надож хоть чутка понимать почему оно делает так а не иначе, и как оно работает, для большей лучшести.
Поясню свою точку зрения, у меня есть теория. Автор решил изучить php, на глаза ему попались микрофреймворки, в силу своей неопытности он не смог разобраться как они работают но очень вдохновленный красотой запуска приложения решил сделать сие чудо. В чем суть моей претензии, в том что пример ужасный. Допустим у вас есть задача, вам нужно выдатаь некий ответ по http. По сути тот код что написал автор вообще не нужен.
1. для реквестов респонсов на php уже куча решений, от простых до сложных. Свой велосипед уже тысячу раз объясняли почему не нужен, если вы крупный ентерпрайз и хотите все свое это "ок", но как обычный девелопер возьмите хотя бы psr-15 любое решение из уже существующих. я уж не говорю про компоненты ларавел и симфони если религия позволяет.
У автора в классе Router создается в !! конструкторе !! объект реквеста, правильно было бы вообще не завязывать класс роутера на реквест, а просто передавать его из RequestHandler как аргумент:
public function resolve(Request $request)
и все роутер не зависит от реквеста, это называется лень.
class Application
{
public Router $router;
public function __construct($ROOT_DIR)
{
$this->router = new Router();
}
public function run()
{
echo $this->router->resolve();
}
}Тут я вообще молчу, верх быдлокода. Какой смысл в переменной $ROOT_DIR которая не используется, какой смысл в этом классе если можно сделать просто:
$request = new Request();(new Router())->resolve($request);
Этот класс просто запускает другой класс, нужно больше абстракций СЭР!!!
про то что на дворе 2022 год PHP 8.1 а в данном коде ни намека на строгую типизацию, вы в добавок учите УСТАРЕВШИЙ ДИАЛЕКТ ЯЗЫКА который если вы сейчас изучаете конечно полезно для легаси проектов, но как автор "фреймворков" вы отстаете от всех лет на 5, ну да работает не трогай верно.
Если вы такое покажете на собеседование вас не то что не возьмут, угарать с вас будут. А если возьмут тимлиды там отбитые конечно (: (не на практику а на фуллтайм)
Ну и еще сразу вопросы. Возможно, конечно моя логика вывернута, но:
Условно есть запрос, ну например, localhost:8080/contact/all
Есть кусок кода, $app->router->get('/contact/', ... ); в index.php
Кусок кода из пункта 2 создает в $routes маршрут.
В моем понимании логично было бы get-том что-то получать, а не создавать.
Ну и в свете этого:
- может Request имеет смысл внутрь Application?
- и $app->router->get($app->request->getPath(), ...); и чтоб он не создавал маршрут, а отдавал что-то ?
- А $routes в Router создать загодя?
Статья плохая, но не потому что код примитивный или тема заезженная.
А потому что это не статья, а репозиторий какой-то.
Фактически здесь только код, с небольшими перебивками типа "а теперь сделаем то-то". Зачем, почему, какое отношение это все имеет к MVC — непонятно. "Сделаем роутер"! Что такое роутер? Где он находится в буквах MVC? Зачем он нам нужен? Нет ответа. Делаем потому что делаем. "Я дерусь… просто потому что дерусь!" (с) Портос.
То же самое про реквест. Какое место он занимает в MVC? Почему мы его создаём? Нет ответа. При том что ценность подобной статьи как раз не в ученическом коде, который никто никогда не будет использовать, а именно в объяснении всех тех действий, которые мы совершаем.
Но видно, что автор и сам не до конца понимает смысла своих действий, и поэтому объяснить их не может. Отсюда появляются смешные ляпы. Казалось бы — при чем здесь .htaccess, если используется встроенный сервер РНР?
Если бы я писал подобную статью для новичков, то взял бы за основу знаменитый текст Symfony versus Flat PHP, и уже от него прокладывал мостик к фреймворку. Чтобы была понятна связь — какой элемент фреймворка соответствует нашему файлику корзина.пыхыпы
Статья явно рассчитана на начинающих. Но без объяснений мы получим из начинающего не программиста, а классического лепилу, который "может написать свой фреймворк!" Ага, так же как он может "написать приложение на Ларавле!" И чуть в сторону от учебника — тут же с вопросом на Тостер, "а как мне посчитать сумму в SQL запросе?"...
Apache в 2022? Где строгая типизация? Автор знает про наличие таких методов как PUT, DELETE и остальных? Зачем $request public? И вообще, какой смысл поста, какую мысль хочет донести автор?
Пост про код из одной строки, но с composer, psalm, codeception, bitbucket pipelines или github actions и docker будет гораздо полезнее, чем вот эта спорная никому не нужная структура, вызывающая массу вопросов.
Апача тут нет, тут используется встроенный сервер :)
В целом я бы сказал что часть этих придирок не по делу. Типизацию — да, надо уже ставить просто на автомате. Но вот про put c delete тут явно не к месту. Понятно что класс реквест не полный, в нем к примеру не разбирается инпут, который куда важнее, чем пут :)
Но это как раз нормально, чтобы не загромождать код и текст. Код из одной строки и псалм вообще не к месту, у автора про другое.
Я это к тому, что статья хоть и заслуживает критики, но критики адекватной, а не "почему про докер не написал?"
хоть кто то в здравом уме тут еще остался )))
похожие вещи пишутся обычно на всяких курсах, типа скиллбокса от 0 до про
Материал имеет место быть. Вспомнил себя лет 15 назад, когда тоже что то подобное лепил. И здесь показана общая структура построения практически любого MVC.
Сейчас конечно нужно идти в ногу со временем, уже PHP 8.1 и я за строгую типизацию.
Из таких простеньких "скелетов" иногда вырастают настоящие фреймворки, масса примеров за прошедшее десятилетие.
Если автор не остановится и будет развивать свой проект, то наверняка рано или поздно, как и я, придёт к полноценному фреймворку со своей архитектурой и back-end'ом.
Пишем мини MVC фреймворк на PHP #1