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

Я не спрашивал твое мнение про "можно" и "нельзя".  Спросил вполне конкретный вопрос

Как отделить тех кто это сделал ради навара? А в твою голову не приходит вариант, что если отменить такой налог, то стоимость жилья поползет вверх из "частников" которые "я честно - честно частинк, просто купил и только потом понял что не подошло".

Ты опять сел на своего абсолютно тупого коня? Я своим вопросом какое то выводы или мнение озвучил?  Ведь потом опять скажешь, что у меня цель жизни опустить тебя.  Постройся ка удерживаться в адекватном русле разговора.

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

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

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

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

Эта миссия не выполнима :) Всегда одному будет слишком тихо, другому слишком громко, слишком упрощенные термины, слишком профессиональные термины, быстро/медленно.... и еще 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