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

Для пользователя (тот что на уровне шаблона уже) это будет выглядеть так

<!-- стили конкретного шаблона конкретного компонента -->
%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. все решается на уровне шаблонов. Т.е. пользователь должен знать html, css, если ему нужно js плюс язык шаблонизатора (примерно как и у тебя)

CMS - строится на основе фреймворка, имеет и шаблонизатор и панель управления. Т..е все по классике. Пользователю надо ее знать, знать html если нужно, но уже возможно все в интерфейсе делать не залезая в файлы

Конструктор сайта - тут вообще пользователь не должен ни чего знать. Накидывает мышкой в веб интерфейсе блоки, заполняет поля в формах-конфигурации блоков, возможно какие-то пошаговые мастера запускает и отвечает на вопросы. Тут вообще не нужен ни html ни css.

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

В моей классификации твой фреймворк это смесь фреймворка и CMS.  И именно смесь. На моем можно создать Rest API сервис в котором не будет ни какого html и шаблонизатора, не будет работы с БД.... т.е. будет легкое ядро.

По сути мой фреймворк с моим шаблонизатором будут требовать ровно столько же знаний сколько и твой. (единственно у меня не будет на этом уровне админки), но она будет отдельным модулем, когда до нее дойдет время.

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

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

В любом случае нет смысла сейчас на словах это все обсуждать. У тебя есть доступ к коду обоих проектов, так что есть возможность сравнивать на техническом уровне, а не так. Опять же у меня прогресс есть, у тебя нет пока :) 

Какие, например, ты имеешь ввиду?

Вопрос отложено вызвал такие мысли "по поводу" :)

Если оторваться от челенджа и просто уже думать что такое фреймворк (не только мой, а в принципе) и зачем он нужен. То монетизация заключается в скорости разработки на нем: а она складывается из многих факторов, в т.ч. удобство, наличия нужного функционала "из коробки" и т.п.

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

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

Возвращаясь к моему проекту: любая фича - это как миниму попытка сделать удобнее и быстрее разработку конечному пользователю. (а пользователь в данном случае разработчик)

Форум тоже будет открытый. У меня есть проект который монетизирован.  Да и вообще форум - по стольку по скольку. Я уже запланировал как миниму два готовых решения на фреймворке и есть задумка третьего, но пока не уверен, что стоит отвлекаться. (и будут реализованы до форума)

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

По поводу XML точно нет.

1 Для конфигов у меня используются объекты, что гарантирует правильные типы значений и самодокументируемость. 

2. Использовать XML в том виде как у тебя реализовано, я по прежнему считаю плохой идеей, гораздо  больше убивающей производительность. В принципе если вывести некоторый функционал из твоей идеи и использовать xml именно как "язык шаблонизатора" - вполне себе вариант. (но нет я пойду иначе).

А так у меня была идея, уже после того как ты хотя бы опубликуешь доку на свой XML. Просто продемонстрировать, что в моем фреймворке при желании можно использовать твои шаблоны.  Именно шаблоны. т.е. парсинг другой, но  с возможностью подключать твои компоненты (те что про вывод блоков на страницу)

Но в идеале: решить одну задачу на обоих фреймворках (например ТЗ я как то тебе предлагал на другом форуме), подключить к одной БД, на одном сервере и сделать небольшое нагрузочное тестирование.

На первом этапе (тут все же я хочу успеть сделать форум, а идей в голове даже на ядро уже накопилось дофига - но для реализации форума они не нужны. Это скорее про то, какой функционал нужен фреймворку для широкого диапазона проектов):  анализ метки времени файла для понимания что файл в публичной зоне протух (если ты про статику). Если про генерацию самой страницы. То задача шаблонизатора и системы кеширования.  Шаблонизатор я уже ранее тут публиковал. Его разработка на паузе (нужны были изменения в ядре). текущее состояние на github.  Он отдельным модулем. (все же фреймворк рассчитан и на проекты где может и не быть фронта). Ну и будет скелетон (рабочее название joke-site) где этот модуль будет сразу в комплекте.

Создавайте на моем фреймворке CMS платную и вперед :)

Смотря что подразумевать под API: классические JSON-эндпоинты или просто любые маршруты в целом.

Тут речь про любые маршруты которые в ответ отдают HTML. Т.е. например "по классике"   мы имеем объект Response который в мидлварах "насыщается" теми же заголовками . И я подразумеваю, что может быть полезно дать гибкости для случая когда ответ отдается в HTML.   На примере симфони (если я правильно понимаю) у него есть вебпрофайлер, который подписан на событие ответа и если ответ text/html, то ищет закрывающий боди и докидывает туда свой кусок html. Так же бывают решения в проектах когда в head дописывают что либо.  Тут предполагаю что не будет необходимости "искать" ни head ни закрывающий body.

Будет:

- контент (все что будет вставлено в body)

- список js файлов которые нужно подключить на странице

- список css файлов которые нужно подключить на страницы

- "произвольные" строки для head

- дополнительно коллекции атрибутов для тега body и head

И все это будет жить по частям до момента отправки ответа.

Т.е. потребовался нам вывести отладочную информацию: модулю не надо искать body: добавил стили/скрипты в список и добавил к свой кусок к body.  Подключение счетчиков поисковых систем, можно оформить в виде мидлваров, и они будут докидывать все что нужно.

Ну а далее уже перед отправкой все это собирается в целый html: генерится полноценный html-head-body. Где нет дублей например скриптов. (например когда есть шаблонизатор, на странице в разных частях шаблона положили некий компонент (возможно с разными данными), но который хочет подключить свой скрипт и стили. Т.е. он зарегал, а этот билдер обеспечит чтобы этот скрипт и стили были подключены только один раз, переложит их в доступное из-вне пространство, если он еще не кешировался и не был изменен с прошлого копирования). возможно так же проверит нет ли min версии файла. (тут есть еще полет для мысли - можно минимифицировать на этом этапе, склеить, и т.п.)

так же , например скрипты можно будет добавлять в head или вниз страницы (указывать при добавлении куда его надо)

Ну а более детально уже расскажу когда в релиз выйдет. Т.к. даже уже сейчас несколько трансформировалось от начального видения. :)