Wrong MVC - система созданная для создания других систем...

Зачем это нужно Вам?

Управление бизнес логикой

Для разделения и распределения абсолютно любой Вашей бизнес-логики! Менеджмент, пользователи, покупатели, заказчики, доставщики, руководители, водители и их родители, могильщики и похоронщики - благодаря групповым политикам доступов ко всем моделям, легко организовать и построить абсолютно любую архитектуру и подчиненность процессов в любых Ваших приложениях и управлять ею онлайн! А в сочетании со встроенной автоматизацией по расписаниям - это пушка бомба. Это не CRM система, это среда разработки на базе которой можно построить любую свою систему, включая CRM!

Нет ничего проще сайта в два клика?

Тогда запускайте лендинги в 1 клик

Что за зверь такой?

Чуточку подробнее про Wrong MVC

Вложенность назначаемых прав доступа не ограничена. Совсем! Ничем! Что это значит? Это значит возможность создания любого функционала многоуровневой вложенности в проекте и простота корректировки его логики работы в дальнейшем. Администратор с наивысшими правами системы может делигировать определенные функции другим пользователям, создавать группы администраторов, модераторов, с разными доступами и функционалом, включать и отключать их. Аналогично по цепочке вниз, пользователи могут управлять делегированным им функционалом других пользователей.

Архитектура WRONG в плане разграничения прав пользователей относительно похожа на доступы в системе Linux. Существуют группы пользователей и даже специальная группа "Система". Только здесь - это реализация на PHP + MySQL, роутинг страниц, архитектура прав, это всё подтягивается из записанных в БД данных.

Действия, выборки, страницы, всё это доступно определенной группе(группы доступа) и имеет группу-владельца(владелец имеет права на изменение или удаление, добавление групп и на сам доступ). У групп могут быть подчиненные группы.

У каждого действия или модели(компонента), будь то api-http запрос/выборки/страницы/модалки, есть массив "Группы доступа" и единственная "Группа владелец"

Если брать аналогию с Linux то "Группы доступа" - имеют право на чтение и выполнение, а "Группа владелец" имеет плюс к этому ещё право на запись.

Например, "Модератор" создает страницу с REQUEST_URI = /example-page и соответствующий ей файл - обработчик /example-page.php , с правами доступа группам "Гости", "Пользователи". Указанные группы имееют доступ к странице(она "читается" и "выполняется"), а вот включать, отключать, удалять, изменять группы которым она доступна, это уже "запись", это может сам владелец страницы - группа "Модератор" или пользователи с правами выше(группа "Администраторы"). Естественно что владелец всегда имеет право и на доступ.

Так же со всеми действиями, выборками, модальными окнами, группами пользователей, всё имеет свои права и владельца. Даже функционал и страницы главного Администратора подчинены группе "Система", чтобы админ не смог "выключить" самого себя или критически важный функционал - начальные параметры системы.

Тем не менее пользователь создаваемый при установке состоит не только в группе "Администраторы" но и в группе "Система", но функционал данной группы защищен от отключения и удаления, а вот вносить правки в "Группы доступа" можно.

Как и в Linux пользователь может принадлежать одновременно нескольким группам, причем для этих групп могут быть заданы страницы/запросы с одинаковыми REQUEST_URI, но различными файлами-обработчиками. Как же мы определяем какую страницу отдать по одному и тому же REQUEST_URI? Всё просто. Каждой группе пользователей назначается "вес"(weight) и запрашивается страница с запросом соответствующим группе с большим весом. Тоже самое с действиями/модалками и прочими запросами к api(они тоже имеют REQUEST_URI и файлы-обработчики)

Например, Администратор состоит в группах "Администраторы", "Модераторы", у тех и других групп есть одинаковые REQUEST_URI. Но вес группы "Администраторы" больший чем вес "Модераторов", и будет отдан обработчик именно "Администраторов", в то время как группе ниже может быть отдан другой обработчик по тому же URI запросу. Можно создавать любое количество групп с различными названиями и весом! Чем больше вес - тем больше прав. Пользователь группы с меньшим весом не может управлять пользователями(и их функционалом) с большим весом(удалять, выключать, изменять и т.д.)

Модели(компоненты). Всё что имеет группу-владельца является моделью, будем называть компоненты так - модель. Таких типов моделей в системе 8:

• Группы пользователей
• Пользователи
• Шаблоны
• Страницы
• Выборки
• Модальные окна
• Действия
• Cron задачи

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

Группы пользователей. У каждой группы есть свойство - системный вес. От веса зависит приоритет одного пользователя над другим. Пользователь может состоять одновременно в разных группах с разным весом, в данном случае для расчета приоритета(веса) пользователя берется максимальный вес из групп в которых он находится.

Вес в системе. Что такое приоритет одного пользователя над другим? Это значит что пользователи из "подчиненной группы"(с меньшим весом) могут управляться пользователем с большим приоритетом(макс. вес его групп больше). Т.е. он может отключать, удалять таких пользователей и создавать для них различные действия, модальные окна, страницы, назначать их владельцами данного функционала, отключать им определенный функционал. Естественно это всё в рамках того функционала, который включен и доступен данному пользователю.

Управление по кнопке. Пользователи, группы пользователей, страницы, действия, модальные окна, здесь всё отключается и включается кнопочками вкл/выкл! Кроме того, ссылки на вызов отключенных окон, линки на такие REQUEST_URI, не показываются на других даже доступных пользователю страницах. Тоже самое если юзер вне "Группы доступа", он просто не увидит таких ссылок, если они будут у него. И конечно получит 403 если запросит url вручную. Это всё - ав-то-ма-том! Что это значит? Это значит мы выключили страницу или модалку для пользователя - нам даже не нужно менять верстку шаблонов, у него автоматически будут скрыты все ссылки/кнопки на этот функционал(средствами CSS), а обработчик запроса перестанет работать.

Роутинг uri запросов к моделям автоматический и учитывает вес. У пользователей могут быть страницы с одинаковым REQUEST_URI, но с разными файлами обработчиками и контентом в них. При этом пользователи могут находится в одних группах. Например пользователь 1 состоит в группе "администраторы" и "пользователи", а пользователь 2 состоит в группе "пользователи". Вес групп пользователя 1 больше. И есть 2 разных модели типа "страница" с одинаковым REQUEST_URI. Но для пользователя 1 доступны обе страницы, а для пользователя 2 только одна. В результате URI контроллер отдаст пользователям разные страницы, т.к. пользователю 1 будет отдана страница наиболее подходящая по его весу групп.

Страницы могут иметь одинаковый основной контент, но различные шаблоны. Например это страница со списком документации для не авторизованных и главная страница админки. Как уже сказано выше они могут иметь и одинаковый url, а шаблон будет зависеть от группы пользователя.

Модальные окна - их полно, но их просто нет!:) Обычные бутстраповские модальные окна, на первый взгляд, но их html кода на страницах нет. Окна подтягиваются автоматически из api по ajax и уничтожаются из DOM при их закрытии. Это позволяет очень гибко реализовать в них js логику и менять их как перчатки, перемещаясь "внутри" логики окон. Для примера - страницы регистрации/авторизации/восстановления пароля. Окна и действия создаются в админке из готового шаблона, а дальше правим на свой вкус. Но это не всё! Все data-* атрибуты с кнопки триггера модального окна, добавятся переменными к GET запросу api отдающему модалку. А в data-callback="MyFynction" можно указать даже имя callback функции которая будет вызвана после добавления в DOM кода модалки. Конечно реализован и javascript программный вызов окон функцией, с callback обработчиком. Взгляните как просто на этой странице вызывается модальное окно входа в систему. Обычный bootstrap триггер: data-toggle="modal" data-target="#sign-in", но сам код модального окна запрашивается из api и добавляется в DOM автоматически.

Действия. Всего лишь data-action="my-action" атрибут к любой ссылке и любая ссылка/кнопка/элемент автоматически превращается в триггер при клике связанный с api, автоматом отправляющий POST request на апи /api/action/my-action, при этом все данные data-* атрибутов переменными POST массива летят на этот запрос, имеется автоматическая модалка(прокладка) подтверждение с кастомизацией текстов да/нет(если нужна - добавляем data-confirm="true"), callback функция с response от api обработчика(добавляем data-callback="MyFunction"). По умолчанию в response от обработчика приходит json формат, но и это легко меняется data-response="script|html" и вуаля - любой формат в апи ответе. И всё это, ав-то-ма-том! data-* атрибуты рулят! Естественно действие(апи запрос) заранее должно быть добавлено в админке, с требуемым ему разграничением прав. Там же есть конструктор кнопок с data-* атрибутами. То есть фактически, любая кнопка автоматом превращается в "мини" форму, отправляющую данные с возможностью получить ответ от api. Обычные формы по сути запросов не отличаются. Это легко и просто! Также есть программный вызов действий javascript функцией с передачей параметров и callback обработчиком.

Выборки в таблицах моделей реализованы плагином DataTable и имеют все необходимые сортировки по столбцам, постраничную навигацию и поиск по таблицам, все состояния таблиц сохраняются. Есть быстрое редактирование всех необходимых параметров в таблицах. Имеется удобный лог действий, с подсветкой ошибок, который отключается для групп пользователей. В таблицах имеется настройка скрытия ненужных столбцов таблиц, а также фильтрация моделей по группам доступа, владельцам и активности. Таблицы - лишь визуализация моделей системы, в вашем проекте это могут быть любые иные обработчики и визуализация, но работать они будут в той же глобальной api структуре выборок /api/select/.. и будут относиться к моделям типа "выборка".

API. Абсолютно все действия в системе от пользователей выполняются при помощи api запросов. Запросы авторизуются как посредством сессии пользователей, так и посредством X-Auth-Token. Авторизованные X-Auth-Token запросы отключаются как на уровне настроек всей системы, так и на уровне настроек для каждого отдельного пользователя. Практически неограниченные возможности для расширения! Даже эта система может являться частью другой системы или проекта, быть управляема ею извне по api, или же сама стать проектом со своим собственным api.

CRON задачи настраиваются в админ панели с абсолютно идентичным синтаксисом crontab расписания в Linux. Имеется удобный предпросмотр расписания ближайших выполнений. Но в данной логике по крону выполняются не файлы, а выполняются любые внутрисистемные http запросы, которые могут быть авторизованы X-Auth-Token любого пользователя(если у него включено api). Указывается лишь id исполнителя задачи. С http запросами можно отправлять любые заголовки и POST/PUT/DELETE данные, опять же для взаимодействия с api системы. Это позволяет работать с функционалом по расписанию, например включать и отключать определенные сервисы-модели(действия, страницы, пользователей, группы, настройки и т.д.) в определенное расписанием время. Cron задачи являются такой же моделью как и все остальные модели системы и подчинены общей логике групповой политики доступов.

Импорт, экспорт, копирование моделей. Любую модель можно легко экcпортировать и импортировать как внутри системы, так и между системами на базе WRONG MVC. Экспорт отдает архив модели со всеми потрохами = строка в бд + файл обработчик(если он есть у модели) При импорте будут созданы файлы и записи в необходимых таблицах моделей. А если делается импорт уже существующей в системе модели - к именам файлов, записям, запросам, добавится автоматически префикс copy. Т.е. если у нас есть некий функционал(действие, страница, модалка) и нам нужно создать такой же, но с "перламутровыми пуговицами". В этом поможет быстрый экcпорт/импорт/копирование.

Вёрстка и её шаблоны. В проекте предусмотрен gulp сборщик фронтенда, вы можете собирать любые собственные модификации фронтендов. Javascript работает с вёрсткой Bootstrap v4.6.1, поэтому его верстка нужна(в любой модификации). Если же все фронт js плюшки(модалки и прочее) вам не нужны - то не нужен(оставляем рабочим лишь бекенд - контроллеры, крон, роутинг, а встроенный js не подключаем в проекты). Можно создать любую страницу для входа в панель, отключив эту, а в шаблонах проектов использовать любой свой бутстраповский css по вкусу, или даже стек файлов для разных шаблонов, меняя бутстраповские дизайны хоть каждый день или отдельным пользователям или под любые странички или по cron задачам на праздники. Для системной панели же, лучше оставить встроенный дизайн. Вне панели, javascript можно подключать внизу шаблона, это не критично. Необходимые js/css плагины можно подгружать в шаблоны по их путям даже напрямую из любого каталога фс, при этом они будут автоматически минифицированы. Вы можете создавать любое количество сборок и вариаций различных фронтендов. Для примера посмотрите на файл шаблона этой страницы и на файл контента этой страницы. Как видите контент и шаблон разделены и практически не зависят друг от друга.

Выше, изложено лишь сумбурное описание системы. В документации изложено уже систематизированное описание методов, свойств, разделов, api и возможностей. На базе Wrong MVC можно создать практически любой расширяемый проект, будь то движок многостраничного портала, интернет магазина, или движок многофункционального web сервиса.

Откуда взялся?

Начинающий нелюбитель, учусь систематизировать и автоматизировать пушки бомбы