Я не предлагаю отдельную папочку для файликов сайта - все это давно есть в любом фреймфорке. Я предлагаю отдельную папочку для файликов сайта, которая может располагаться где угодно на диске, а не только в папочке движка. И это есть вопрос архитектуры.
проблема указана в начале пассажа: "где угодно на диске, а не только в директории движка"... В современных фреймворках сайты могут размещаться только в спец-директории самого движка. Это есть ограничение, согласитесь.
Сайты Lev могут размещаться где угодно на диске, а не только в директории движка. И это основное достоинство архитектуры Lev.
Как "движок" может сформировать страницу без "сайта"? - согласен с вами, никак. Поэтому движок Lev формирует страницу сайта обращаясь к настройкам страниц самого сайта.
"Вы говорите, что СУБД не нужна, но сами реализуете свою собственную СУБД, работающую на файлах..." - я говорю, что СУБД не нужна для реализации основных функций движка. Я не могу говорить, что СУБД не нужна вообще нигде и никогда. Lev не реализует свою СУБД, для поиска или перебора файлов Lev пользует обычные функции файловой системы.
"Как будто конфиги в yaml - это что-то уникальное для Lev" - вы правы, я как-то не очень аккуратно выразился...
Как Грав, так и Лев не то что не заточены под какое-либо бизнес приложение, они не имеют даже СУБД. По той причине, что оба являются чисто движками, т.е. чисто обслуживают сайты (анализируют запрос браузера, формируют страницы, ...).
Магазины, форумы и любое иное бизнес приложение может быть размещено в сайте. При этом ключевой особенностью Лев является то, что его сайты отделены от движка, т.е. могут быть размещены где угодно на диске.
Не совсем так. Запрос браузера получает сайт. И вызывает любой доступный движок для формирования ответа. Движок формирует страницу ответа (исходя из данных именно этого сайта) о возвращает ее браузеру.
Если сайт использует модель MVC, то "маршрутизатор, все контроллеры и модели" будут сидеть в сайте, а не в движке. И никакого объединения ежа с ужом тогда нет.
Я вообще-то больше про принцип: сайт и движок - это разные штуковины. И про то, что они могут сидеть где угодно на диске. И про то, что движков может быть много, и любой сайт может обращаться к любому движку.
Я вижу так: в сайтостроении есть два основных объекта — сайт и движок. Они совершенно разные.
Базовая схема их взаимодействия такая:
Сайт получает запрос браузера на страницу. Он обращается к движку с просьбой о помощи. Движок анализирует запрос браузера на предмет какая страница запрошена, формирует контент страницы обращаясь к настройкам сайта и возвращает готовую страницу браузеру.
То бишь всю работу производит движок.
А что же делает сайт? А сайт занят бизнес-логикой и настройками (определениями) страниц. Сайт не формирует страницы, он их только определяет.
Если есть два основных объекта «сайт» и «движок», то, по идее должны быть два основных класса, которые определяют свойства и методы этих объектов.
Так вот, я знаю, что в топовых фреймворках нет своего класса для сайта, а во многих нет даже класса для движка. Почему нет? Потому, что свойства этих классов сидят в конфигах, а их методы разбросаны по всему фреймворку. Это плохая архитектура.
Далее. Я взял неплохой фреймворк Grav. Он, как и большинство фреймворков, поддерживает квази-мультисайт, это когда все мультисайты сидят в некоем спец дире самого фреймворка. И попытался для него полностью отделить сайт от движка. Это получилось - движок в своем дире, сайт - в своем где угодно на диске. Правда, пришлось существенно перелопатить движок.
Как-то так. Хотелось бы обсудить тему с вами детальнее...
Я вижу так: у фреймворка есть два основных объекта — сайт и движок. Они совершенно разные.
Базовая схема их взаимодействия такая:
Сайт получает запрос браузера на страницу. Он обращается к движку с просьбой о помощи. Движок анализирует запрос браузера на предмет какая страница запрошена, формирует контент страницы обращаясь к настройкам сайта и возвращает готовую страницу браузеру.
То бишь всю работу производит движок.
А что же делает сайт? А сайт занят бизнес-логикой и настройками (определениями) страниц. Сайт не формирует страницы, он их только определяет. А бизнес-логика - это основная задача сайта. Сайт магазина содержит приложение для магазина, данные по товарам в СУБД, и определения всех своих страниц.
Итак, если есть два основных объекта «сайт» и «движок», то, по идее должны быть два основных класса, которые определяют свойства и методы этих объектов. Согласны?
Так вот, я знаю, что в топовых фреймворках нет класса Site, а во многих нет даже класса Engine. Почему нет? Потому, что свойства этих классов сидят в конфигах, а их методы разбросаны по всему фреймворку. Это плохая архитектура.
А насчет «вы засунули весь фронтенд в один класс?» даже не знаю, что сказать. Нет, не засунул. Я сторонник глубокой декомпозиции классов.
Вот для этого и сгодится СУБД. Только она будет жить не в движке, а на сайте. Т.е. в приложении сайта. Кроме того, есть готовые плагины для многих пользователей.
А вот форум - это приложение со своей СУБД, его просто размещаем на сайте и все.
Большинство конфигов неизменно в рамках одного запроса.
Пользователи хранятся в файлах конфигов, один конфиг на одного юзера. Эти файлы могут меняться в рамках запроса. Поиск в конфиге делается в классе User спец методами - простым перебором.
«коды сайта» - это коды бизнес-приложения сайта. Скажем, сайт магазина имеет приложение для управления товарами. Это и есть бизнес-приложение, причем именно сайта. К движку оно не имеет никакого отношения, поэтому живет оно на сайте.
Движок тоже имеет свое бизнес-приложение. Оно управляет всеми сайтами движка.
Мука отделена от хлеба. Страданий нет — все счастливы
Я не предлагаю отдельную папочку для файликов сайта - все это давно есть в любом фреймфорке. Я предлагаю отдельную папочку для файликов сайта, которая может располагаться где угодно на диске, а не только в папочке движка. И это есть вопрос архитектуры.
проблема указана в начале пассажа: "где угодно на диске, а не только в директории движка"... В современных фреймворках сайты могут размещаться только в спец-директории самого движка. Это есть ограничение, согласитесь.
лады. принято
Сайты Lev могут размещаться где угодно на диске, а не только в директории движка. И это основное достоинство архитектуры Lev.
Как "движок" может сформировать страницу без "сайта"? - согласен с вами, никак. Поэтому движок Lev формирует страницу сайта обращаясь к настройкам страниц самого сайта.
"Вы говорите, что СУБД не нужна, но сами реализуете свою собственную СУБД, работающую на файлах..." - я говорю, что СУБД не нужна для реализации основных функций движка. Я не могу говорить, что СУБД не нужна вообще нигде и никогда. Lev не реализует свою СУБД, для поиска или перебора файлов Lev пользует обычные функции файловой системы.
"Как будто конфиги в yaml - это что-то уникальное для Lev" - вы правы, я как-то не очень аккуратно выразился...
Как Грав, так и Лев не то что не заточены под какое-либо бизнес приложение, они не имеют даже СУБД. По той причине, что оба являются чисто движками, т.е. чисто обслуживают сайты (анализируют запрос браузера, формируют страницы, ...).
Магазины, форумы и любое иное бизнес приложение может быть размещено в сайте. При этом ключевой особенностью Лев является то, что его сайты отделены от движка, т.е. могут быть размещены где угодно на диске.
Сущность "сайт" есть, она сейчас в конфигах. Класс Site пока тестируется.
С инструкциями вообще беда - помогите, мы пока не успеваем...
Пока единственный способ - демо-сайт в папке demos дистрибутива.
Ну и хелп от предка Grav соответствует во многом.
я имел в виду более глобальный бэкап - всего сайта... такие ведь тоже нужны...
Не совсем так. Запрос браузера получает сайт. И вызывает любой доступный движок для формирования ответа. Движок формирует страницу ответа (исходя из данных именно этого сайта) о возвращает ее браузеру.
Если сайт использует модель MVC, то "маршрутизатор, все контроллеры и модели" будут сидеть в сайте, а не в движке. И никакого объединения ежа с ужом тогда нет.
Я вообще-то больше про принцип: сайт и движок - это разные штуковины. И про то, что они могут сидеть где угодно на диске. И про то, что движков может быть много, и любой сайт может обращаться к любому движку.
Как-то так...
я про PHP. или даже вообще про принцип: сайт и движок - это разные штуковины. за коммент спасибо
Я вижу так: в сайтостроении есть два основных объекта — сайт и движок. Они совершенно разные.
Базовая схема их взаимодействия такая:
Сайт получает запрос браузера на страницу. Он обращается к движку с просьбой о помощи. Движок анализирует запрос браузера на предмет какая страница запрошена, формирует контент страницы обращаясь к настройкам сайта и возвращает готовую страницу браузеру.
То бишь всю работу производит движок.
А что же делает сайт? А сайт занят бизнес-логикой и настройками (определениями) страниц. Сайт не формирует страницы, он их только определяет.
Если есть два основных объекта «сайт» и «движок», то, по идее должны быть два основных класса, которые определяют свойства и методы этих объектов.
Так вот, я знаю, что в топовых фреймворках нет своего класса для сайта, а во многих нет даже класса для движка. Почему нет? Потому, что свойства этих классов сидят в конфигах, а их методы разбросаны по всему фреймворку. Это плохая архитектура.
Далее. Я взял неплохой фреймворк Grav. Он, как и большинство фреймворков, поддерживает квази-мультисайт, это когда все мультисайты сидят в некоем спец дире самого фреймворка. И попытался для него полностью отделить сайт от движка. Это получилось - движок в своем дире, сайт - в своем где угодно на диске. Правда, пришлось существенно перелопатить движок.
Как-то так. Хотелось бы обсудить тему с вами детальнее...
Благодарю за советы. Хотел бы обсудить с вами. Попытался пойти в вашу личку https://habr.com/ru/conversations/1tiger1/ - но там все серое типа заблокировано...
в статье есть ссылки на гитхаб: https://github.com/getlev/lev
Я вижу так: у фреймворка есть два основных объекта — сайт и движок. Они совершенно разные.
Базовая схема их взаимодействия такая:
Сайт получает запрос браузера на страницу. Он обращается к движку с просьбой о помощи. Движок анализирует запрос браузера на предмет какая страница запрошена, формирует контент страницы обращаясь к настройкам сайта и возвращает готовую страницу браузеру.
То бишь всю работу производит движок.
А что же делает сайт? А сайт занят бизнес-логикой и настройками (определениями) страниц. Сайт не формирует страницы, он их только определяет. А бизнес-логика - это основная задача сайта. Сайт магазина содержит приложение для магазина, данные по товарам в СУБД, и определения всех своих страниц.
Итак, если есть два основных объекта «сайт» и «движок», то, по идее должны быть два основных класса, которые определяют свойства и методы этих объектов. Согласны?
Так вот, я знаю, что в топовых фреймворках нет класса Site, а во многих нет даже класса Engine. Почему нет? Потому, что свойства этих классов сидят в конфигах, а их методы разбросаны по всему фреймворку. Это плохая архитектура.
А насчет «вы засунули весь фронтенд в один класс?» даже не знаю, что сказать. Нет, не засунул. Я сторонник глубокой декомпозиции классов.
Вот для этого и сгодится СУБД. Только она будет жить не в движке, а на сайте. Т.е. в приложении сайта. Кроме того, есть готовые плагины для многих пользователей.
А вот форум - это приложение со своей СУБД, его просто размещаем на сайте и все.
Как-то так...
Большинство конфигов неизменно в рамках одного запроса.
Пользователи хранятся в файлах конфигов, один конфиг на одного юзера. Эти файлы могут меняться в рамках запроса. Поиск в конфиге делается в классе User спец методами - простым перебором.
ссылка https://getlev.org/Lev/downloads которая отвечает за скачивание не работает - да, не работает, не реализовано, но мы над этим работаем...
Папка demos пустовата потому, что в ней определены всего 2 демо-страницы.
субд нет потому, что не нужна - в статье все сказано. Данные хранятся не в субд, а в конфиг-файлах.
«коды сайта» - это коды бизнес-приложения сайта. Скажем, сайт магазина имеет приложение для управления товарами. Это и есть бизнес-приложение, причем именно сайта. К движку оно не имеет никакого отношения, поэтому живет оно на сайте.
Движок тоже имеет свое бизнес-приложение. Оно управляет всеми сайтами движка.
Мука отделена от хлеба. Страданий нет — все счастливы