Александр Воробьев

Требуют налог с какой суммы?

На я зарегался вообще без проблем. Пройдя процедуру верификации через госуслуги.

кто сказал? Я ИП и вроде как мне не запретило создавать

У меня с рабочего компа перестали уходить, с хостинга пока отправляются. Планирую на макс перекинуть уведомлялки

Эта миссия не выполнима :) Всегда одному будет слишком тихо, другому слишком громко, слишком упрощенные термины, слишком профессиональные термины, быстро/медленно.... и еще 100500 "т.д и тп.".  Разве что нейронки научаться генерировать персонализированный контент.  Но: вот мы посмотрим всем форумом (Каждый у себя дома) 500ую серию условного "гарри поттера". А поговорить будет не о чем - т.к. у всех своя серия :)

Я про условие "если хочет джсон то .... иначе...."

Ну собственно пример выше :), на ларавель тоже можно.

Единственное НО. Обычно для апи и веба разные миддлвары подключают. (настройка на уровне маршрутов и групп маршрутов). В контроллер мы попадаем уже через все эти миддлвары. В АПИ, как правило, не нужны сессии и SCRF токен, но нужен JWT...  и там тоже тогда надо проверять с чем работаем?  Или речь всегда о стейтлес работе?

В плане роутинга мне больше нравится подход как в ларавель. В симфони с его стремлением везде использовать атрибуты (а ранее в phpDoc) мне совсем не заходит. (именно по этому я и сделал больше похожим на лару).

В моем понимании создавая контроллер я не знаю как и зачем он будет использоваться. И на какие маршруты отвечать. Это не ответственность кода контроллера. Это ответственность системы маршрутизации. Если у меня на проекте возникла причина поменять маршруты. (ну условно изменит /api/ на /my_best_api/ - как очень упрощенный частный случай) - то я недолжен лезть в код и проходить все контроллеры.

одни и те же маршруты (а точнее контроллеры) работать с разным типом контента не проблема. Раз уж речь зашла о симфони. тут я покажу сразу в одном примере два маршрута, но суть полагаю понятна - маршрут может остаться и один.

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;

class BlogController extends AbstractController
{
    #[Route('/api/blog_create', name: 'api_blog_create')]
    #[Route('/blog/create', name: 'blog_create')]
    public function new(Request $request): Response
    {
        if ($request->getPreferredFormat() === 'json') {
            return $this->json([
                'status' => 'success',
                'message' => 'Это ответ в формате JSON для API',
                'data' => ['id' => 123]
            ]);
        }

        return $this->render('blog/new.html.twig', [
            'message' => 'Это HTML-страница'
        ]);
    }
}

Но!  На мой взгляд этот подход не правильный.  Контероллер должен быть тонким.  что в твоем, что в моем коде есть лишнее условие, которое решаемо на уровне роутинга. Тут, имхо, нарушение и солид (надо дополнить апи, но трогаем класс, который не имеет отношения к апи), SoC - смешиваем логику ответа условно для непосредственного отображения человеку, и обработки программно,  пожалуй KISS. Потом rest обычно подразумевает более широкий спектр статусов ответов...  ну понято, что ты привел просто пример, но все же нужная ли это фича? :)

А они все плюс минус одинаково. Блейд так же примерно. На самом деле я хотел пойти несколько иным путем, но именно тут была реплика, что разработчикам было бы удобнее видеть нечто привычное.  я подумал подумал и ....  но повторюсь пока это проект.   У меня база шаблонизатора уже пережила три варианта, и лишь когда осознал направление куда двигаться вернулся к фреймворку - там не хватало например механизмов интеграции модулей удобной  (а шаблонизатор это модуль) :)

Единственное у меня в шаблонах будет только то, что внутри body, остальное декларативно описывается и передается (под капотом) генератору... (посмотрим что из этого выйдет в итоге :) - но хочу попробовать)

--- del

Это варианты для разных уровней.

Нужен и оправдан на проекте шаблонизатор. Значит используем шаблонизатор и шаблоны, соответственно html  с тегами шаблонизатора.  Шаблонизатор сам взаимодействует с билдером.

Если шаблонизатор на проекте избыточен, но нужно управление статическими файлами  -используем только билдер.

Если и билдер избыточен можем совсем по простому. Вот варианты обработчика маршурута (специально, для демонстрации обработчики в виде колбеков (конечно по хорошему они в виде классов реализуются, но можно и так:

// Уже доступно. Возвращается просто строка, готовый HTML. 
// Преобразуется в HTmlResponse который, при необходимости согласно логике, насыщается, например, заголовками
$router->get(
    '/var1',
    static fn() => <<<'HTML'
        <html><head></head><body><ul>
            <li><a href="/name/Alex">Hi Alex</a> Текстовый ответ. Имя можно менять</li>
            <li><a href="/json/Alex">Hi Alex</a> Json ответ. Имя можно менять</li>
        </ul></body></html>
        HTML,
);
// Уже доступно. Возвращается уже готовый HtmlResponse, если есть у нас такая необходимость
$router->get(
    '/var2',
    static fn() => new HtmlResponse()->setBody(<<<'HTML'
        <html><head></head><body><ul>
            <li><a href="/name/Alex">Hi Alex</a> Текстовый ответ. Имя можно менять</li>
            <li><a href="/json/Alex">Hi Alex</a> Json ответ. Имя можно менять</li>
        </ul></body></html>
        HTML),
);
// Над этим работаю. 
$router->get(
    '/var3',
    static fn(HtmlBuilder $builder) => $builder->setBody(<<<'HTML'
        <ul>
            <li><a href="/name/Alex">Hi Alex</a> Текстовый ответ. Имя можно менять</li>
            <li><a href="/json/Alex">Hi Alex</a> Json ответ. Имя можно менять</li>
        </ul>
        HTML)->build(),
);
// Это уже с модулем шаблонизации. HTML где то лежит/формируется согласно правил шаблонизатора
$router->get(
    '/var4',
    static fn(Templator $templator) => $templator->build(),
);

т.е. имеем четыре зарегистрированных url которые будут отдавать одинаковую страницу, но формировать ее разными способами