Ну я вижу применение в 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 или вниз страницы (указывать при добавлении куда его надо)
Sly32#: Если не лень, расскажи поподробнее. Насколько это нужно?
Вообще просто решил "гипотизу проверить". Показалось что может быть удобным держать html страницу в разобранном виде. Изредка бывали на проектах ситуации , когда сформированную страницу перед отправкой есть необходимость исправить. и начинается регулярки и т.п.... (правда там речь о CMS, возможно на уровне фреймворка это и не так полезно)
На определенный маршрут может быть отдан HTML ответ. И это не зависит от наличия шаблонизатора. Возможно вообще какие либо технические ответы потребуются, а может быть ситуация обработчик маршрута сгенерировал html ответ, добавил стили и скрипты. (опять же как частный случай - практически "пустая" техническая страница, на проекте где нам шаблонизатор даже не нужен.) Еще кейс: какой то мидлвар, по условиям логики проекта, захочет добавить подключение скрипта, или дополнить тело страницы (как частный случай отладочная информация в debug режиме). Т.е. по идее шаблонизатор генерит только body страницы. и отдает его билдеру (ну и регистрирует скрипты которые хочет подключить).
Билдер: обеспечивает что скрипт подключится один раз (если его подключали несколько раз из разных мест), на данный момент будет еще и кеширование обеспечивать. т.е. можно подключить скрипт из недр проекта (файл будет лежать за пределами корня сайта), билдер его перенесет согласно настроенных правил в подкаталоги корня сайта. (в будущем думаю добавить этап "компиляции" и это будет все менее важно). Т.е. он имеет условно: список скриптов которые хочется подключить, список файлов стилей, которые хочется подключить, список мета тегов и тело страницы.... и уже только непосредственно перед отправкой собирается все в html.
Изначально думал отдать это все шаблонизатору, но вот в частности размышления как показать те же дебаги, подумал, что это пусть будет в ядре.
У меня, если честно, есть некоторые сомнения в полезности. И это все пока "прототип" который будет работать. решил попробовать эту идею. Ведь как раз удобно в таком проекте затестить гипотезу.
По идее завтра очередной спринт завершается. Но у меня тишина (НУ очень насыщенные две недели задачами были). Особо "рапортовать" не о чем. И все же фиксирую, как переход к спринтам по месяцу.
[2/12] Было много разъездов и работы не на основном компе в режиме "пока жду" и "между делом". По этому несколько веток стартовало по фичам. (но не на гитхабе), больше скорее там не про код, а про проектирование.
Например задумал добавить генератор html, не путать с шаблонизатором - это другой слой. Шаблонизаторы будут взаимодействовать с ним. Это функционал для управления, например, подключением статических файлов, мета-тегов.... в этой точке, например, можно будет переключать статику на cdn.
Ну и сложилась в голове картинка "форума" каким буду его делать.
Юлия#: Общий фон, к сожалению, действует на всех. Неуловимо. Разрушающе. Через других людей. К примеру, родных и близких. Они залипают в социальных сетях, глупеют, общей массой начинают передавливать твоё мнение, заставляют сомневаться, тянут вниз. И даже если ты отбиваешься, то силы тратишь, энергию, которую можно было бы направить на что-то созидательное...
Ну уж не совсем все так плачевно. Вот буквально полчаса назад подписчик выражал благодарность, за знания полученные из наших видео (каналы не ИТ, и не про "как стать успешным" - просто определенная ниша, профессия). Просто надо тоже понимать: никто 24/7 только и исключительно полезное не смотрит. Кроме того: работа, бытовые хлопоты и т.д и т.п. И вот уже в оставшееся время распределяем и на отдохнуть и на поучиться.
Полагаю получается так, что развлечения тут и заходят всякая подобная шняга (тут на вкус и фломастеры разные), и зрители приходят из разных сфер, а вот полезное видео уже все разбегаются по нишам, все разные. в итоге сервисы ранжируют больше развлекуху. Но и полезный не совсем списывается. просто не надо просмотры сравнивать.
Тут опять же накладывается и то, что хорошее видео требует много времени иногда и денег. И у кого у кого только канал уже монетизации может не хватать, вот и список авторов уменьшается (у нас, например, связка оналйн сервис + каналы)
Опять же: вот я сейчас загружаю видео полезное, и короткое примерно 20мин, а бывает час.... И тут уже нужно выбрать время, иногда купить материалы, чтоб сразу и попробовать.... А фигную - включил, выключил :) Опять же в транспорте
Сергей про е-ком#: 4. Цвет шрифтов читается, вайб делает серым на сером )
Кстати, чисто субъективное мнение. Взгляд споткнулся (в негативном смысле), на шрифтах заголовков (на контентбокс) например "не потеряйте доступ в релиз". Полужирный италик съел пространство между слов - и плохо читается.
(Но я ни разу не дизайнер - просто как постетитель)
ArbNet#: Проект должен быть реально рабочий, а не на гитхабе или в картинках
Ну строго говоря, мой проект уже можно использовать. И примером готовое приложение TODO листа. Да простенько, но тем не менее по инструкции можно поставить и пользоваться ;)
ArbNet#: Уже было хотел начать, как на меня кредит повесили которого я не брал, к старому счёту к кредитке которая уже не действительна и по которой я все выплатил 13 лет назад. Кому-то в прошлом году выдали другую кредитку и повесили её на мой счёт, тот по ней совершал покупки и переводы.. Короче обращался в полицию и тд.
Ну это просто взрослая жизнь. И у каждого свои проблемы и задачи разного уровня, в т.ч возникающие внепланово, и увы я тоже не исключение.
PS Кстати, когда машину отдавал в ремонт (ну кто читает тему про китайские авто в курсе ДТП) и забирал. В первые лет за 25 общественным транспортом воспользовался по межгороду. И умночаты вполне себе развлекаловка на время поездки. По архитектуре пары модулей "пообщался", некоторые моменты изучил, которых раньше не приходилось касаться.
Ну я вижу применение в 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мин, а бывает час.... И тут уже нужно выбрать время, иногда купить материалы, чтоб сразу и попробовать.... А фигную - включил, выключил :) Опять же в транспорте
4. Цвет шрифтов читается, вайб делает серым на сером )
Кстати, чисто субъективное мнение. Взгляд споткнулся (в негативном смысле), на шрифтах заголовков (на контентбокс) например "не потеряйте доступ в релиз". Полужирный италик съел пространство между слов - и плохо читается.
(Но я ни разу не дизайнер - просто как постетитель)
Таким вайбкодингом веет)) я этот дизайн вижу во многих новых проектах. Вайбдизайн
P.S: новая версия, сегодня финал тестов и запуск.
"Learn Service" или прям банально - "Репетитор"
Проект должен быть реально рабочий, а не на гитхабе или в картинках
Ну строго говоря, мой проект уже можно использовать. И примером готовое приложение TODO листа. Да простенько, но тем не менее по инструкции можно поставить и пользоваться ;)
Уже было хотел начать, как на меня кредит повесили которого я не брал, к старому счёту к кредитке которая уже не действительна и по которой я все выплатил 13 лет назад. Кому-то в прошлом году выдали другую кредитку и повесили её на мой счёт, тот по ней совершал покупки и переводы.. Короче обращался в полицию и тд.
Ну это просто взрослая жизнь. И у каждого свои проблемы и задачи разного уровня, в т.ч возникающие внепланово, и увы я тоже не исключение.
PS Кстати, когда машину отдавал в ремонт (ну кто читает тему про китайские авто в курсе ДТП) и забирал. В первые лет за 25 общественным транспортом воспользовался по межгороду. И умночаты вполне себе развлекаловка на время поездки. По архитектуре пары модулей "пообщался", некоторые моменты изучил, которых раньше не приходилось касаться.