В плане роутинга мне больше нравится подход как в ларавель. В симфони с его стремлением везде использовать атрибуты (а ранее в 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
А это как-то так, будет движком интерпретатором обработчиком %команда% будет?
$response-> по моему более лучший вариант для тебя
Это варианты для разных уровней.
Нужен и оправдан на проекте шаблонизатор. Значит используем шаблонизатор и шаблоны, соответственно 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 которые будут отдавать одинаковую страницу, но формировать ее разными способами
Точно нет, даже для случая когда пользователь программист если он применяет шаблонизатор. Если же он использует только билдер, то да, тут пишется именно в обработчике маршрута и тут про код по определению
$response->builder->addHeadScript(__DIR__.'/script.js');$response->builder->addCss(__DIR__.'/custom.js');$response->setBody('<div class="desiogn">Hello Alex</div>');
Так те в которых надо декларировать настройки страницы, где указываются какие css, js файлы надо подключить, какой шаблон, мета теги и тд.
ЗЫ. У меня это всё прописывается в XML инструкции к странице. У тебя я так понимаю будет php файл с подключением классов и в объектах указыватся параметры, настройки.
Для пользователя (тот что на уровне шаблона уже) это будет выглядеть так
<!-- стили конкретного шаблона конкретного компонента -->%include styles.css%%include styles.js defer%<button>%caption%</button>
%layout public%%include /main/style.css%<div class="some_block">%component vendor.super.button%</div>
Конечный синтаксис еще не утвержден, но примерно как то так
Ну нет, по моим наблюдениям совсем обратный вывод. Причем вариант более жесткий. Битрикс это вам не ларавель в плане лишнего. :) И тем не менее вот мой проект (тот что с монетизацией). САПР это модуль к битриксу. Там работы дохрена. Нужно ли мне переписывать функционал предоставляемый битриксом? (в модуле он конечно в минимальных количествах) Если переписывать то что бы что?:
Тут скорее по принципу "какой вопрос такой и ответ". Ведь если присмотреться внимательнее к теме речь не про монетизацию. Основная цель изначально была заявлена и там нет ни слова о том, что это проект про какую либо коммерческую выгоду. Человек зашел и спросил про монетизацию, ну я и предложил вариант монетизации. Таким образом "вперед" = "вперед монетизируйте"
Такс. понятно. читать ни кто не любит? Специально для таких случаев в документации есть отдельная статья зачем этот проект
Должен ли меня заботить этот вопрос? Этот вопрос заботит другого участника форума. Вдруг он бог маркетинга и сможет продвинуть CMS созданную на моем фреймворке в топы :D. Обещаю, что если хотя бы даже какие то намеки на это будут, то и для меня статус проекта изменится на более серьезный.
То есть, чтобы пользователю создать на твоём фреймворке страницу нужно изучить как надо создавать объекты для формирования страницы и тп. То есть твоим фреймворком смогут пользоваться только те кто знают PHP, масса пользователей отпадают, от сюда масса проблем для пользователей для создания новых страниц и тд. Ясно-понятно..
Ну все идет от понимания, что такое фреймворк. (мне кажется я уже писал тут свое представление)
Фреймворк - инструмент разработчика. Да на этом уровне нужны хотябы минимальные знания php и документация по фреймворку.
Фреймворк + шаблонизатор. В принципе, если подготовлен костяк сайта, здесь уже не нужен php. все решается на уровне шаблонов. Т.е. пользователь должен знать html, css, если ему нужно js плюс язык шаблонизатора (примерно как и у тебя)
CMS - строится на основе фреймворка, имеет и шаблонизатор и панель управления. Т..е все по классике. Пользователю надо ее знать, знать html если нужно, но уже возможно все в интерфейсе делать не залезая в файлы
Конструктор сайта - тут вообще пользователь не должен ни чего знать. Накидывает мышкой в веб интерфейсе блоки, заполняет поля в формах-конфигурации блоков, возможно какие-то пошаговые мастера запускает и отвечает на вопросы. Тут вообще не нужен ни html ни css.
Естественно на любом уровне можно привлекать разработчика (или выполнять его функции) для добавления новых компонентов и нового функционала.
В моей классификации твой фреймворк это смесь фреймворка и CMS. И именно смесь. На моем можно создать Rest API сервис в котором не будет ни какого html и шаблонизатора, не будет работы с БД.... т.е. будет легкое ядро.
По сути мой фреймворк с моим шаблонизатором будут требовать ровно столько же знаний сколько и твой. (единственно у меня не будет на этом уровне админки), но она будет отдельным модулем, когда до нее дойдет время.
Т.е. если целью ставить и тебе и мне: возможность использовать как можно большей аудиторией, как раз таки у моего потенциал больше. Т.к. для создания сервиса без фронта у тебя уже заложен оверхед. (на сколько я понял, но может, конечно ты однажды продемонстрируешь что то)
Напомню, я все же иду с учетом челенджа, в котором как конечная цель движок форума. Создам движок, там уже вернусь к элементам, которые мне будет на тот момент интереснее расширять. А так приступать к разработке CMS или, тем более, конструктора рано, на мой взгляд должна быть хорошая база сначала. опять же в моем представлении ядро должно иметь гораздо больший минимально необходимый функционал чем есть у тебя (на тот момент, что у меня есть твой код).
В любом случае нет смысла сейчас на словах это все обсуждать. У тебя есть доступ к коду обоих проектов, так что есть возможность сравнивать на техническом уровне, а не так. Опять же у меня прогресс есть, у тебя нет пока :)
Какие, например, ты имеешь ввиду?
Вопрос отложено вызвал такие мысли "по поводу" :)
Если оторваться от челенджа и просто уже думать что такое фреймворк (не только мой, а в принципе) и зачем он нужен. То монетизация заключается в скорости разработки на нем: а она складывается из многих факторов, в т.ч. удобство, наличия нужного функционала "из коробки" и т.п.
То есть проект взявший на вооружение тот или иной фреймворк сокращает расходы (и деньги и время) на разработку и сопровождение - а это тоже монетизация.
Единичный разработчик - так же сокращается время, значит за условный месяц может сделать больше задач и получить больше средств. - тоже монетизация
Возвращаясь к моему проекту: любая фича - это как миниму попытка сделать удобнее и быстрее разработку конечному пользователю. (а пользователь в данном случае разработчик)
