Своя MVC на PHP

Программируем ну уровне реализаций?) Ну хорошо, не PSR, а если допустим, другой роутинг внедрить? А что у нас с определителями служб? Где объекты создаются? Ни сервис-локатора, ни контейнера внедрения зависимостей пока не увидел. Но еще посмотрю подробнее, может и ошибаюсь. Тема очень интересная!
--- Добавлено ---
Вот, например, объект View создается new() внутри объекта Controller. Если конструктор для View изменится, весь код переписывать придется. Понимаете, о чем речь? Это и есть программирование на уровне реализаций. А лучше контроллеру отдавать зависимость, на уровне интерфейса.
--- Добавлено ---
Для этого существуют такие паттерны, как ServiceLocator, DI...

 

Насчет внедрения зависимостей лучше пораньше определиться, потому что иначе вся идея может насмарку пойти. Ну сами посудите, если во View вдруг добавится параметр нужный при инициализации, то как быть? Хоть конструктор меняй, хоть сеттер добавляй, один фиг - переписывать все контроллеры. А если их там накопится? И это только то, что навскидку увидал. То, что идея без PSR и без Composer, это, считаю, правильно. Но если нет своих интерфейсов, значит никто не сможет изменить реализацию. Поэтому я бы интерфейсно прикрыл те же View и Controller-ы. У Вас, как я понимаю, наследованием абстрактный супертип реализован?

 

Однозначно. Без Зандстра никак. Там, кстати, все эти дела, применительно к теме, очень хорошо описаны.

 

0 байт страниц Зандстры

 

Есть еще вот эта https://m.vk.com/wall-51126445_84512 она покороче, но лучше всего Зандстра. Фундаментально, и некоторые паттерны описаны только там, в том числе шаблоны корпоративных приложений. Есть еще из серии Head First, но там примеры на Java. Если Вы решили архитектурой заняться, то Зандстра понадобится однозначно.

 

видимо ты её используешь только после вардампа )))

 

если ЧПУ не нужны, то брутальные пацаны делают так:

PHP:

1. class HomeAction
2. {
3.     public function __invoke($id = null)
4.     {
5.         echo __METHOD__;
6.    
7.         var_dump($id);
8.     }
9. }
10.  
11. $routes = [
12.     'GET' => [
13.         '/' => HomeAction::class
14.     ],
15.     'POST' => [
16.  
17.     ]
18. ];
19.  
20. $route = $routes[$_SERVER['REQUEST_METHOD']][parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH)];
21.  
22. call_user_func_array(new $route, $_REQUEST);

путь: /
выхлоп: HomeAction::__invoke null

путь: /?id=100
выхлоп: HomeAction::__invoke string '100'


вот и весь роутер )))

 

@Вероломство, с какого перепуга ?id=100 – это путь? И не забываем, что parse_url может легко возвращать false, т.е. завершаться с ошибкой
--- Добавлено ---
Вообще не тестить наличие ключа в массиве перед обращением к соотв. элементу массива – жесть.

 

а с какого - нет, в корень сайта причапал явный гет-параметр, я так рефки делаю: Ваша реферальная ссылка /?referer=666

с чего бы это мне на моём сайте прописывать такие ссылки?
--- Добавлено ---

а что, мне ещё элементарную проверку параметра ещё сюда прописать или может быть программист сам отвалидирует строку хотя бы в инт положительный?

 

В терминах разберись. В показанном путь – это /, id=100 – строка (GET-)параметров, вопрос – разделитель.

Полученное в $_SERVER['REQUEST_URI'] «прописывает» юзер, а не ты

 

в пути /?id=100 мы имеем явный гет-параметр id, что ещё не ясно программисту?

с чего бы это мой сайт будет обрабатывать то, что прописал пользователь, если в массиве роутов этой дичи - НЕТ

пользун должен вести себя на МОЁМ сайте так, как это предусмотрел - Я, нажать ссылку, которую прописал - Я

 

1. Не покрывай try-catch объёмные блоки, в целом достаточно одной строчки, углубляясь в вызов которой, ты словишь throw
2. /src/helpers.php это какой-то прикол, для этого есть Live Templates в шторме или какой-нить аналог в твоём редакторе.
3. В шаблонах старайся избегать прямого написания кода, пока все это глаз не особо сильно режет, а когда пойдёт логика - потом сам офигеешь.

PHP:

1.         <?php if (!empty($error)): ?>
2.             <div style="background-color: red;padding: 5px;margin: 15px"><?= $error ?></div>
3.         <?php endif; ?>

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

PHP:

1. $errorContent = '';
2. $pageContent = file_get_contents('some_template.tpl');
3. if($error) {
4.     $errorContent = $error->getMessage();
5. }
6. $pageContent = str_replace('{error}', $errorContent, $pageContent);

Очень примерно, но в эту степь можно пойти и дальше наворачивать логики, добавить условий аля smarty/twig и прочее.
4. На твой сайт можно отправить данные, через POST с другого ресурса, с подставленными зловредными данными, придумай как валидировать то, что данные тебе приходят от тебя самого. Погугли CSRF.

PHP:

1. <label>Email <input type="text" name="email" value="<?= $_POST['email'] ?? '' ?>"></label>

5. Зачем ? Используя "as" ты можешь переименовать для удобства или решая одноименность.

PHP:

1. use MyProject\Models\Articles\Article as Article;
2. use MyProject\Models\Users\User as User;

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

 

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

Я бы поспорил, т.к. в соло программировать и не смотреть на остальных, что у них и как - можно прое*ать кучу времени и слепить из себя говнокодера.

 

Именно, зачем изобретать PHPMailer или обвязку для cURL?
Бывают, конечно, залёты, использовал какой-то валидатор данных, он оказался несовместим с PHP8, автор пропал куда-то, пришлось руками править )

 

Не нравится нативная шаблонизация пыха, используйте другие шаблонизаторы, но только с пред. компиляцией в нативные шаблоны. Использовать at run time str_replace для шаблонов (а не для контента) – это жесть.

 

Ну хз, я слепил из себя сеньёра. Почти в двух языках. Могу сказать, что нативное понимание сути вещей, закреплённое хоть одним велосипедом, в разы круче, особенно в рамках сменяемости тех или иных технологий. Зри в корень.

Why not ? Изобрети, как pet-project. Я свой самопис потаскал по парочке компаний, задачи выполняло отлично.
Вот сейчас мне бы не помешала штука для выливки на продакшон, достаточно специфичная. Это конечно чуть жестче чем обвязка для курла, но и не как мейлер.

Ну это как само-собой. Среди разнообразия шаблонизаторов полно хороших решений. Лично мне всегда smarty нравился, просто потому, что я консерва и он был первым из.

Жесть, не жесть, начинать надо с чего-то, потом уже ob_flush() и прочие прелести.

Работаю с проектом, легаси юи, вырвиглазное говно в плане верстки. Мои глаза слишком привыкли к хорошему.