Команда разработчиков

Пока это похоже на обычный шаблонизатор с подгрузкой блоков, где каждый блок имеет свой неймспейс и стили/JS код привязанный к нему.

Посмотрите на Google Web Toolkit, там почти то же самое, используются компоненты, с описанным интерфейсом, а HTML + CSS + JS генерируются через кодоген.

Может не будем городить костыли, а начнем писать в таком случае реактивные компоненты Vue, React, Angular, Ember. Много уже написано, знай применяй к своим задачам.

Сейчас классический HTML CSS безбожно устарел и не нужно на этом зацикливаться. Фронтенд должен быть отдельно и жестко не связан с бекендом. Иначе все шансы остаться в прошлом веке еще на долго.

А чего одному такому умному со своей собственной супер-коцепцией не получается справиться - командной работы захотелось?

ArbNet, давно уже сказали - сделай хотя бы элементарный сайт (просто текстовые страницы), чтоб "хоть что-то работало", да выложи на всеобщее обозрение. Получишь кучу обратной связи (возможно, даже конструктивной)..

Пока это похоже на абстрактную сферическую теорию в вакууме.

Примеры кода, которые приводил ТС в своей предыдущей теме далеки от общеизвестных и рекомендуемых - ему довольно много комментариев накидали.

Абстрактный "XML", который всё сделает за пользователя.. почему-то застрял на начальных этапах.. и вот сейчас - новый заход.. "в командную работу" (типа "сделайте за меня"?)

ArbNet , возможно, есть уже реально работающий хотя бы мало-мальски функциклирующий.. сайт, сделанный "по XML-фэншую"?

Так а смысл тогда темы такого рода сюда выкладывать? 😂 Значит, не в разработчиках дело.. 🙅

---------- Добавлено 12.03.2020 в 15:24 ----------

p.s. И да, командную работу лучше начинать с участия в качестве "просто" участника, а не "предводителя" и "идеолога" aka тимлида..

То есть у вас есть компонент формы который использует бутсрап и jquery, а у меня компонент слайдера, который использует материал цсс и ангруляр, добавив 2 компонента на один сайт там будут 2 цсс фреймворка, джиквери и ангуляр? Отличный подход объединить фронт и бэк.

То что вы пишите, называется MVC, при том вы из всего это пытаетесь сделать только V, как будет работать M непонятно, где хранить инфу - непонятно. Вам выше написали, что хотят взять файл описания сущностей, отдать во фреймворк, а на выходе получить схему БД и напиленные модели, но видимо что это мне вам будет не объяснить. И далее буква C - выраженная тем файликом php с бизнес логикой. В итоге вы делаете франкенштейна похуже битрикса, в битриксе это хотя бы продумано и напилено огромное ядро с кучей полезных функций, а не как у вас. В вашем случае нет даже никакого ассет манагера, который бы проверил что 10 компонентов не подключают 10 разных джкверей. И вот таких ньюансов много и вам их всех будет не запилить физически, а они в других уже запилены, отсюда профита заниматься вашей поделкой нет никакого. А если все подключения выносить в общий лэйаут, то смысла от вашего компонентного подхода нет, так как они начинают быть сильносвязанными, а это плохо, просто так введя в админке плагин уже не установишь.

Кстати, что-то похожее было релизовано лет *цать назад в onphp

https://habr.com/ru/post/94972/ - статья на хабре

https://github.com/onPHP/onphp-framework - github (не отслеживал, насколько актуальное и рабочее)

Абсолютно не верно.. Наоборот я отказываюсь от костылей, прикручивания этого, потом ещё этого, я делаю своё, но в комплексе, шаблоны с стилями и скриптом для фронта, и php класс для бека если нужна обработка.

ivan-lev, такое много где реализовано, вообще генерировать схему и связи это одна из задач ORM. Но фреймворков с интеграциями я не знаю. Например, ты описываешь сущность:

use {MaxLen, Required, Unique, WriteOnly} from "constraints"

type User {
    id: uuid,
    login: String, MaxLen(16), Required, Unique, 
    password: Bytes, WriteOnly,

    operations {
         create, read, update, delete, patch,
    }

    HasMany {
         ![]Post
    }
}

type Post {
    id: uuid,
    content: String, MaxLen: 4096, Required,
    url: String, Unique,
    HasOne {
        !Author: User, 
    },

    operations {
         create, read, update, safeDelete, patch,
    }
}

Сгенерируются таблицы:

CREATE TABLE users (
    id UUID PRIMARY KEY,
    login TEXT NOT NULL UNIQUE CHECK(char_length(login) < 16),
    password BYTEA NOT NULL
)

CREATE TABLE posts (
    id UUID PRIMARY KEY,
    content TEXT NOT NULL CHECK(char_length(content) < 4096),
    author_id UUID NOT NULL REFERENCES(user),
    url TEXT NOT NULL UNIQUE,
    is_deleted BOOLEAN NOT NULL DEFAULT FALSE
);
CREATE INDEX posts_url_idx ON posts USING HASH(url);

• operations описывает операции, там где safeDelete - удаление будет заменено на UPDATE ... SET is_deleted = true,
• там где HasOne, HasMany - объявляется связи у сущности
• после типа указывается констрейнты, которые пробрасываются и на уровень субд, и на уровень хендлеров данных, выбрасывая ошибки (которые тоже можно описать, унаследовав от констрейнтов)
• в DDLках указаны все констрейнты и даже использован индекс на основании unique констрейнта

В итоге, гарантируется валидность данных самой СУБД, можно делать обход графов, можно генерировать таблицы не только под PostgreSQL, но и под другие СУБД (MySQL, MariaDB, TinkerPop/Gremlin, и т.д.). Можно делать модели vue, которые потом подмешивать в свои страницы/компоненты. Генерируется сервер с нужными хендлерами (а под них и клиент, например axios+typescript).

Вообще, подозреваю, что такое уже есть. Я вот как раз стартовал свой проект на склейке из двух подобных инструментов (OpenAPI, ent), а получил кучу ограничений про которые не знал в процессе написания. То ORM генерирует дикие запросы (это можно побороть), то нет поддержки uuid в первичном ключе. То нет курсоров по строкам. И т.д.

А очередной XML конвертер в HTML имхо не особо нужен.

Так джанга вроде ведь делает ?

Что-то из этого может и умеет, но точно не все. Вообще, не хватает декларативного языка в котором можно будет описать все необходимое для проекта в 2к20, а имплементацию сгенерировать под любой язык. А-ля grpc и protobuf, указал данные, указад rpc методы, кнопочку нажал, и получил интерфейсы, которые осталось реализовать/сшить с уже имеющимися сервисами.

Лучше через репозиторий это делать