Если запарываетесь над терминологией, то в переводе на русский под ваше определение "библиотеки" подпадает, пардон, Библиотека имени Ленина. И под определение "каркаса" подпадает каркас из арматуры для заливки фундамента. Не под моё. Это какому ж поносу надо было в голову стукнуть, чтобы в разговоре о PHP- и JS-фреймворках вдруг подумать, что Cron - это тоже фреймворк, на котором кто-то пишет PHP- или JS-проект? Вы свой фантастический Cron-код пишете вперемешку с PHP? И Cron обрабатывает запрос и передаёт в ваши контроллеры? Если да, то с веществами завязывайте. Может для Вас это сюрприз, но все фреймворки для HTTP в PHP и JS построены на работе с HTTP, мать его, Message. И все фреймворки в PHP умные люди по поддержке PSR-7, мать его, HTTP Message Interface и PSR-15, мать его, HTTP Server Request Handlers делят на: - Поддерживающие PSR-7 и PSR-15 (Zend Expressive, Slim, Laravel+Bridge) - Поддерживающие только PSR-7 (CakePHP, Symfony+Bridge) - Не поддерживающие ничего (Zend MVC, Yii, CodeIgniter, Phalcon) И осознанно выбирают из них первые PSR-совместимые, если собираются писать фреймворконезависимый проект. Если фреймворк поддерживает PSR-7, то это PSR-7-совместимый фреймворк или, сокращая для заголовка, PSR-7-фреймворк. Если не использует, то это просто фреймворк.
Я ни над чем не запарываюсь. Я всего лишь говорю, что ваше снажру-внутри-с-местами не является ни полным, ни частичным определением фреймворка. Потому что даже крон под него формально попадает. И да я в курсе что это абсурдно. Нет, не так - ЭТО АБСУРДНО. Где я утверждал обратное? А это тут при чем. Я сказал ровно то, что имплементация PSR-7 и иже с ним не превращает код в фреймворк, точно так же отсуствие имплеметации не мешает фреймворку таковым быть. Опять откровение. Где я утверждал обратное? --- Добавлено --- Вы привыкли позиционировать себя как гуру (вот это вот "Ура, вы меня уговорили!"), но внезапно, есть люди которые имеют равную или даже большую компетенцию (заметьте, я ни где не утверждал что я имею большую, более того из всех засветившихся в этой теме я далеко не на первом месте) - это нормально. Не нормально забрасывать определениями, терминами и кодом в надежде что они повлияют на всех тут точно так же как на джунов ищущих видосики на ютубе. Мы тут тоже местами умеем и в хитрую терминологию и в нагрузки и в прочие рэббиты с кафками. p.s. тема себя изжила. скучно.
А с чего вообще Вы про PSR-7 утверждали прямое или обратное? С чего вдруг название "PSR-7 фреймворк" не понравилось и породило протест "PSR-7 это имплементация, а не фреймворк"? Не так поняли? Или всё же чисто из спортивного интереса психанули, чтобы со мной и об этом на ровном месте поспорить? Это только под вашу интерпретацию ваш крон подпадает. Если не умеете в текст без картинок, то нашёл иллюстрацию кто где находится, чтоб Вы со своими кронами нам больше не флудили: И но каждый слой для рассчётов и других действий может дёргать любые свои или сторонние библиотеки. Если путаетесь с местами, то вот Вам домашнее задание:
о боже мой. Имплементация ~ реализация. Термин вообще не может противопоставляться фрейморку, ну это как галоша и топор, хз как доступнее объяснить... Так это я спрашиваю, с чего это я что-то там утверждал? Это ж вы мне спич толкнули про PSR-7 в современных фрейморках. Я лишь сказал, что в процессе выяснения терминологии мы уже до PSR-7 докатились, а воз никуда не сдвинулся ) И ещё раз. Я в курсе что означают все эти страшные слова и прекрасно понимаю всё то, о чем говорю. --- Добавлено --- чей та? 1. у проекта библиотеки внутри проекта, а фреймворк снаружи проекта Крон снаружи проекта, вот прям вот снаружи что ваще. В то же время мы выяснили, что это недостаточное условие. Потому как либа nodejs/http в простейшем случае инициируется аналогичным кодом с фреймворком expressjs, более того, они находятся в одних местах и снаружи ничего нет. 2. Тот дирижёр, который бутстрапирует проект, организовывает процесс и является обвязкой запуска основного нашего кода - то и есть фреймворк. Я как человек закончивший музыкальную школу хз кто там у вас дирижер, но "бутсрапирует" и "организовывает" - это вообще процесс во времени. Если же вам претит конкретно крон, то можно взять любой другой event dispatcher, не по времени, а, ну скажем, по получению http message? (мне ж не надо объяснять уважаемому гуру, что request по которому kernel стартует handler это тоже СОБЫТИЕ?)
Демагогия дистиллированная. Фу. Грубить завязывай, вещества тут не при чем. А, хотя это подворотня. Продолжай.
Ну вот же Вы первый лично утверждали: до моего спича в ответ на этот ваш вопрос. А после спича передумали и на попятную пошли, что это уже не важно. Это склероз или намеренно в показаниях путаетесь? Вот мы и хз как объяснить ход ваших мыслей от фреймворка до psr-7 и его имплементаций. И почему Вам приспичило в "PSR-7 - это всего лишь набор интерфейсов... мать его... всё это вместе реализованное - не обязательно фреймворк" противопоставлять или сравнивать галошу и топор. И реально ли такой мозговой кульбит объяснить вообще. А каркас фундамента дата-центра ну вот ващее-ващее снаружи даже крона. Только вот каркас фундамента - это фреймворк для построения фудамента, а не PHP-проекта. Каркас Avaya SDDC - это фреймворк для построения ЦОД. Каркас SCRUM - это фреймворк для построения менеджмента проектов. Так и фреймворками для построения PHP-проекта будут именно PHP-фреймворки. И именно каждый из них будет наружным каркасом для своего проекта. А не ваши левые Cron, jQuery, браузер и кнопка включения. Пардон, но мы-то как раз подробно и выяснили, что: И как раз потому, что http.Server и express находятся на одних местах снаружи и выше их как раз ничего нет. Поэтому из этого к: видим, что Вы прекрасно и по своему понимаете что говорите, но, видимо, туго понимаете что читаете. Ну так постепенно докопаетесь, что, как мы тоже говорили, код PHP-kernel в bin/worker.php является фреймворком для PHP-кода проекта, а не Cron. А из крона, апача или из pub/sub в него request прилетел - абсолютно не важно. Скопировать код из amqplib/examples или конфиг из README и обезьяна сумеет. А чтобы осилить IoC с control flow в runtime, DIP и coupling уже IQ повыше нужен. Так что у каждого своё "И".
Если наш код раскрасить, то сразу видно, кто кого дёргает и кто у кого внутри: Интерфейсы библиотек (если нужны) лежат прямо в папках Controlers, UseCases и Entities прямо внутри проекта. Там они и вызываются. Реализации интерфейсов - в служебной папке Infrastructure, к кругам не относящейся. А физически могут лежать где угодно: хоть по слоям, хоть в одной куче в папке src или vendor.
@ElisDN теперь у меня сложилось впечатление, что ты приравниваешь фреймворк к его роутеру. Потому что иначе понять что ты объясняешь никак. Роутер вызывает контроллер, но дальше компоненты фреймворка используются точно как либы на твоём скриншоте. К микрофреймворкам, в которых кроме PSR ничего больше нет, это с натяжкой еще можно применить, но давать такие определения полноценным фреймворкам всё же неправильно.
Да, именно так. В минимальном случае, как мы показали с expressive и http.Server, внешний HTTP-фреймворк состоит из App/Kernel + Request-Response и Router. Для обслуживания может ещё использоваться Container. И именно эта обвязка запускается первой снаружи в index.php и уже она запускает контроллеры проекта. Остальное (БД, мэйлер, шаблонизатор и т.п) уже мы сами дёргаем как обычные либы. На микрофреймворках структура раз отчётливо видна. Ты понимаешь, из чего состоит сам фреймворк. И когда самостоятельно выбираешь и подключаешь стороннюю библиотеку для БД понимаешь, что ты её не из фреймворка взял, а сам её к проекту руками подключил. А на полноценных уже такой осознанности нет. Возникает иллюзия, что весь js/http – это библиотека, а весь Symfony - это фреймворк. Но если покопаться внутри, то можно заметить, что полноценный скелетон Symfony по обязанностям состоит из: HTTP-фреймворка symfony/framework-bundle, состоящего как раз из пакетов config, di, http-kernel, http-foundation, event dispatcher и router. CLI-фреймворка symfony/console. И десятков опционально подключаемых независимых компонентов-библиотек. Так что полноценный Symfony – это как раз большой комплект из HTTP- и CLI-микрофреймворка и отдельных либ. Фактически это мега-фреймворк. Разница лишь в масштабе, что брать за фреймворк: ядро или весь комплект. Но Control Flow всё равно тот же самый, как Вы и сказали: компоненты из комплекта используются как простые библиотеки. И в микро-, и в макро-фреймворках.