Ну я вижу применение в api эндпоинтах. Или не уловил смысла?
Смотря что подразумевать под 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 или вниз страницы (указывать при добавлении куда его надо)
Вообще просто решил "гипотизу проверить". Показалось что может быть удобным держать html страницу в разобранном виде. Изредка бывали на проектах ситуации , когда сформированную страницу перед отправкой есть необходимость исправить. и начинается регулярки и т.п.... (правда там речь о CMS, возможно на уровне фреймворка это и не так полезно)
На определенный маршрут может быть отдан HTML ответ. И это не зависит от наличия шаблонизатора. Возможно вообще какие либо технические ответы потребуются, а может быть ситуация обработчик маршрута сгенерировал html ответ, добавил стили и скрипты. (опять же как частный случай - практически "пустая" техническая страница, на проекте где нам шаблонизатор даже не нужен.) Еще кейс: какой то мидлвар, по условиям логики проекта, захочет добавить подключение скрипта, или дополнить тело страницы (как частный случай отладочная информация в debug режиме). Т.е. по идее шаблонизатор генерит только body страницы. и отдает его билдеру (ну и регистрирует скрипты которые хочет подключить).
Билдер: обеспечивает что скрипт подключится один раз (если его подключали несколько раз из разных мест), на данный момент будет еще и кеширование обеспечивать. т.е. можно подключить скрипт из недр проекта (файл будет лежать за пределами корня сайта), билдер его перенесет согласно настроенных правил в подкаталоги корня сайта. (в будущем думаю добавить этап "компиляции" и это будет все менее важно). Т.е. он имеет условно: список скриптов которые хочется подключить, список файлов стилей, которые хочется подключить, список мета тегов и тело страницы.... и уже только непосредственно перед отправкой собирается все в html.
Изначально думал отдать это все шаблонизатору, но вот в частности размышления как показать те же дебаги, подумал, что это пусть будет в ядре.
У меня, если честно, есть некоторые сомнения в полезности. И это все пока "прототип" который будет работать. решил попробовать эту идею. Ведь как раз удобно в таком проекте затестить гипотезу.
По идее завтра очередной спринт завершается. Но у меня тишина (НУ очень насыщенные две недели задачами были). Особо "рапортовать" не о чем. И все же фиксирую, как переход к спринтам по месяцу.
[2/12] Было много разъездов и работы не на основном компе в режиме "пока жду" и "между делом". По этому несколько веток стартовало по фичам. (но не на гитхабе), больше скорее там не про код, а про проектирование.
Например задумал добавить генератор html, не путать с шаблонизатором - это другой слой. Шаблонизаторы будут взаимодействовать с ним. Это функционал для управления, например, подключением статических файлов, мета-тегов.... в этой точке, например, можно будет переключать статику на cdn.
Ну и сложилась в голове картинка "форума" каким буду его делать.
Ну уж не совсем все так плачевно. Вот буквально полчаса назад подписчик выражал благодарность, за знания полученные из наших видео (каналы не ИТ, и не про "как стать успешным" - просто определенная ниша, профессия). Просто надо тоже понимать: никто 24/7 только и исключительно полезное не смотрит. Кроме того: работа, бытовые хлопоты и т.д и т.п. И вот уже в оставшееся время распределяем и на отдохнуть и на поучиться.
Полагаю получается так, что развлечения тут и заходят всякая подобная шняга (тут на вкус и фломастеры разные), и зрители приходят из разных сфер, а вот полезное видео уже все разбегаются по нишам, все разные. в итоге сервисы ранжируют больше развлекуху. Но и полезный не совсем списывается. просто не надо просмотры сравнивать.
Тут опять же накладывается и то, что хорошее видео требует много времени иногда и денег. И у кого у кого только канал уже монетизации может не хватать, вот и список авторов уменьшается (у нас, например, связка оналйн сервис + каналы)
Опять же: вот я сейчас загружаю видео полезное, и короткое примерно 20мин, а бывает час.... И тут уже нужно выбрать время, иногда купить материалы, чтоб сразу и попробовать.... А фигную - включил, выключил :) Опять же в транспорте
Кстати, чисто субъективное мнение. Взгляд споткнулся (в негативном смысле), на шрифтах заголовков (на контентбокс) например "не потеряйте доступ в релиз". Полужирный италик съел пространство между слов - и плохо читается.
(Но я ни разу не дизайнер - просто как постетитель)
