--- 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 или, тем более, конструктора рано, на мой взгляд должна быть хорошая база сначала. опять же в моем представлении ядро должно иметь гораздо больший минимально необходимый функционал чем есть у тебя (на тот момент, что у меня есть твой код).
В любом случае нет смысла сейчас на словах это все обсуждать. У тебя есть доступ к коду обоих проектов, так что есть возможность сравнивать на техническом уровне, а не так. Опять же у меня прогресс есть, у тебя нет пока :)
Какие, например, ты имеешь ввиду?
Вопрос отложено вызвал такие мысли "по поводу" :)
Если оторваться от челенджа и просто уже думать что такое фреймворк (не только мой, а в принципе) и зачем он нужен. То монетизация заключается в скорости разработки на нем: а она складывается из многих факторов, в т.ч. удобство, наличия нужного функционала "из коробки" и т.п.
То есть проект взявший на вооружение тот или иной фреймворк сокращает расходы (и деньги и время) на разработку и сопровождение - а это тоже монетизация.
Единичный разработчик - так же сокращается время, значит за условный месяц может сделать больше задач и получить больше средств. - тоже монетизация
Возвращаясь к моему проекту: любая фича - это как миниму попытка сделать удобнее и быстрее разработку конечному пользователю. (а пользователь в данном случае разработчик)
Не совсем так. Это другой слой. Т.е. шаблонизатор будет взаимодействовать с этим генератором. Т.е. передавать ему и уже готовый HTML и статические файлы которые надо подключить и все остальное что я описал. И тут получается не какая то "монолитная для описания что нужно подключить к странице", а инструмент позволяющий насыщать страницу всем тем чем необходимо. Т.е. на самом "глубоком" уровне, т.е. обработчик конкретного маршрута действует шаблонизатор (он может быть любым по сути, главное чтоб умел взаимодействовать с сервисом генерации) и генерирует страницу. А далее уже дополнительные уровни. Ну для примера: по каким то причинам мы решили что на для некоторых маршрутов (или группы маршрутов) нужен один счетчик метрики, для других другой, а для третьих вообще не нужен. Создаем конфигурируемый мидлвар. И в настройки маршрутизации подключаем в соответствии с задачей. И эти счетчки будут добавлены на соответствующий страницы. А шаблонизатору об этом даже знать не надо - это не его задача.
По поводу XML точно нет.
1 Для конфигов у меня используются объекты, что гарантирует правильные типы значений и самодокументируемость.
2. Использовать XML в том виде как у тебя реализовано, я по прежнему считаю плохой идеей, гораздо больше убивающей производительность. В принципе если вывести некоторый функционал из твоей идеи и использовать xml именно как "язык шаблонизатора" - вполне себе вариант. (но нет я пойду иначе).
А так у меня была идея, уже после того как ты хотя бы опубликуешь доку на свой XML. Просто продемонстрировать, что в моем фреймворке при желании можно использовать твои шаблоны. Именно шаблоны. т.е. парсинг другой, но с возможностью подключать твои компоненты (те что про вывод блоков на страницу)
Но в идеале: решить одну задачу на обоих фреймворках (например ТЗ я как то тебе предлагал на другом форуме), подключить к одной БД, на одном сервере и сделать небольшое нагрузочное тестирование.
На первом этапе (тут все же я хочу успеть сделать форум, а идей в голове даже на ядро уже накопилось дофига - но для реализации форума они не нужны. Это скорее про то, какой функционал нужен фреймворку для широкого диапазона проектов): анализ метки времени файла для понимания что файл в публичной зоне протух (если ты про статику). Если про генерацию самой страницы. То задача шаблонизатора и системы кеширования. Шаблонизатор я уже ранее тут публиковал. Его разработка на паузе (нужны были изменения в ядре). текущее состояние на github. Он отдельным модулем. (все же фреймворк рассчитан и на проекты где может и не быть фронта). Ну и будет скелетон (рабочее название joke-site) где этот модуль будет сразу в комплекте.
