есть opensource часть

Но там 3 файла

https://github.com/getsimpleadmin/simpleadmin/blob/master/db/schema.rb

и :)?

не понимаю твоего вопроса

Ребят! А где можно свой проект пропиарить, скажем у меня OpenSource для nodejs, какие ресурсы читаете?

Почему миграция повторяет схему. Это первый вопрос...

И имел бы поле namespace у fields и entities

а миграции не должны повторять схему :))))?

Нет. Миграции - это и есть схема

если твоя цель - монетизация проекта, то как варинт гугл эдвордс или яндекс

а есть успешные кейсы?

Думаю что хранить field_type в БД - плохая идея

вообще все зависит от цели и твоей аудитории

почему?

цель сделать крутой продукт, который будет приносить пользу, люди будут экономить ресурсы

Потому что привык к системе, где они прописаны в коде

Думаю надо начать с аддонов и автолодера... Для тех кто устанавливал лару - Pyro имеет некоторые отличия: В пиро папка app почти пуста (в ней все равно можно писать, но, ай белив - это лишнее). То же самое можно сказать и относительно содержимого папок database и resources. The best practice - это держать свой код в аддонах. АДДОНЫ. Каждый аддон - отдельный пакет на пакаджисте (при желании на гите), и, следовательно - имеет свой composer.json, в котором и прописан PSR-4 неймспейс для автолодера. Все аддоны, являются наследниками одного класса, и всего их пока 5 видов: 1. Module - представляет из себя неймспейс и раздел в админке. Может содержать несколько моделей (streams), а так же полей (fields). Стоит заметить, что поля, могут быть реюзабл в пределах одного неймспейса (модуля) для нескольких моделей (streams). Использование определенного поля, определенной моделью и называется связью (assignment). 2. FieldType - тип поля служит для определения правил миграции и дальнейшего взаимодействия с БД, для одной ячейки данных у модели. Он содержит тип поля, но может содержать аксессор, мутатор, схему - классы в которых и описываются эти правила. Отношения - тоже описываются здесь (я не имею ввиду прямого указания модели). 3. Theme - тема. Тут особо нечего - бывают двух видов: админка и фронт. Показываются в настройках в админке (хран в БД). Может быть перекрыто последовательно, из нескольких мест в ФС (самое сильное - .env) 4. Plugin - это тупо плагин твиг. 5. Extension - с ним ситуация, как с бубями в преферансе: "не с чего ходить - ходи с бубей". Внутри может быть размещена любая логика. Оно может быть связано по универсальному ключу с другими аддонами, что, по сути, является еще одним способом расширения с наследованием, но речь сейчас не о нем. Важно, что, несмотря на разделение, благодаря общему родителю, аддоны могут пересекаться классами. Например, не обызательно создавать отдельный аддон для плагина, достаточно создать класс плагина в модуле и подключить его в сервис-провайдере. Это касается почти всего. Класс сервис провайдера может содержать любой из аддонов. МИГРАЦИИ и устройство БД. Платформа стримс имеет свой расширенный мигратор, который способен читать миграции, заданные в декларативном стиле. Файлы миграций создаются автоматически, при скаффолде аддонов определенных типов, а также при скаффолде стрима(модели). The best practice, если мы говорим о модуле, ИМХО - иметь один файл миграции для модуля, в котором описываются все используемые поля, и по одному на каждую модель - в них описываются параметры моделей и принадлежность к ним полей. Важно, что в любой миграции, могут быть использованы стандартные для Ларавел up() и down() методы. БД имеет в названиях своих таблиц жесткую зависимость $app_reference, неймспейса и модели. Структура такова: applications - "корневая" таблица, она имеет связь с applications_domains и это единственные таблицы, имеющие название без префикса. Все другие таблицы имеют в качестве префикса в названии "{$app_reference}_" streams, fields и assignments - это "служебные" таблицы. Они содержат информацию о: - других таблицах с базе и их свойствах (streams) - полях, которыми имеют возможность обладать таблицы (fields) - реальных фактах обладания каких-то таблиц, какими-то полями (assignments) Остальные таблицы имеют жесткую зависимость от описаных выше! "{$app_reference}_{$namespace_slug}_{$stream_slug}" А если стрим (ряд) имеет поле translatable === true, то еще и "{$app_reference}_{$namespace_slug}_{$stream_slug}_translations" Это не все - могут быть еще вариации конфигураций. Не будем на них останавливаться. Когда меняется содержимое служебных таблиц (а это модели ларки), наблюдатель триггерит событие Eloquent, которое, в свою очередь, запускает команду - одну из команд - проводящих маленькую миграцию, соответствующую изменениям. Любые другие таблицы могут быть безболезненно созданы в базе, если только их имена не имеют конфликтов со схемой описанной выше.

допустим, сделал ты крутой проект, а дле чего он нужен, какую пользу он приносит?)

ресурсы на разработку экономить

но ведь это не аргумент. Вопрос в том как эффективнее, проще, производительнее и т.д

каким образом?)

а ты посмотрел демку?

а ты посмотрел демку?

ага

ты на забугорную клиентуру ориентируешься?

А деньги на разработку экономит вот это https://gitlab.com/pyro-plus/exporter-extension

В основном на нее

А деньги на разработку экономит вот это https://gitlab.com/pyro-plus/exporter-extension

мне лично не понятно для чего это нужно

@dmitriystrukov а мультилинг у тебя изкоропки?

Не, пока такой фичи нет, но она в планах

Тебе надо просто брать и копировать это https://github.com/anomalylabs/streams-platform

русского не хватает))