Больше чем Laravel CMS
С момента релиза ORCHID, не менялся и не заявлял, что это супер система подходит для всего и вся. Нет, позиционировался он всегда как платформа для разработки сайтов.
Многие проекты можно уже спокойно делать на CMS, новостные порталы, блоги, интернет магазины и т.п. С этим ORCHID справляется на хорошем уровне. Но как оказалось достаточно мало людей делают “обычные” веб-сайты на Laravel (Наверное стоит дать ссылку, где я рассказывал о том, что это действительно дорого). Большинство делают уже целые системы со своей собственной логикой и требуется больший контроль.
Считаю, что уже пора начать реализацию и для построения нестандартной схемы приложения. В первую очередь это так или иначе бизнес-приложения которые требуют CRUD. Как эталон взял реализацию от компании Microsoft для десктоп приложений. Да да, всё что мы делали уже было раньше, но только не в вебе ;)
Суть реализации Microsoft заключался в разработке продукта Visual Studio LightSwitch — среды разработки, нацеленной на создание line-of-business приложений. В 2016 году заявили о прекращении поддержки из-за Silverlight и переноса всего в новый продукт PowerApps
Если таким продуктом в действительности мог пользоваться, даже человек без глубоких знаний разработки, то нам такой реализации достичь невозможно, но это и не является нашей целью. Почти все технические возможности уже существуют в Laravel или пользовательских реализаций. Мы сосредоточимся только на одном единственном, но очень важном компоненте — Screen.
Screen — это экран приложения, который отображает данные. Экраны основаны на предопределенных шаблонов (Layouts) и всё, что вам нужно сделать это привязать данные.
Layouts — это макет, лучшее объяснением будет, то чем он является:
- Таблица (Table)
- Колонки (Column)
- Строки (Row)
- Графики и т.п.
При этом каждый макет может включать в себя другой макет, то есть вложенность. Например экран делится двумя колонками, в левой поля для заполнения, справа справочная таблица и график. Вы можете придумать свои примеры вложения. Поля указываются точно так же как и в уже существующих “Behaviors”.
В экранах предусмотрены встроенные команды (Screen Command Bar), позволяющие пользователям выполнять методы различные методы.
Хватит теории покажи код!
Черновой вариант класса экрана выглядит так:
namespace App\Core\Screens;
use App\Core\Layout\TestRows;
use App\Core\Layout\TestTable;
use Illuminate\Http\Request;
class DemoScreen
{
/**
* Название экрана
*
* @var string
*/
public $name = 'Advertising';
/**
* Описание экрана
*
* @var string
*/
public $description = 'Demonstrative Advertising';
/**
* Запрос к базе данных
*
* @return array
*/
public function query() : array
{
return [
'test' => 'test'
];
}
/**
* Кнопки экрана
*
* @return array
*/
public function commandBar() : array
{
return [
'create' => [
'displayName' => 'Новая запись',
'description' => 'Создать новую запись',
'method' => 'create',
],
];
}
/**
* Макеты которые использую
*
* @return array
*/
public function layout() : array
{
return [
TestRows::class,
TestTable::class,
];
}
/**
* @param Request $request
*
* @return null
*/
public function methodCreate(Request $request)
{
return null;
}
}Вернувшееся значение запроса автоматически проходит через указанные макеты и строит View.
Что это даст?
В действительности это огромный шаг для платформы в целом, который позволит пользователям строить свои собственные отображения по своей логике и данными.
Реальные кейсы написанные по памяти:
Кейс #1
Я не хочу использовать встроенные классы записей и т.п. А имею сложную логику связанных запросов и мне требуется сгенерировать форму которую заполнит/изменит пользователь.
Кейс #2
Многие мои данные берутся из внешних источников MongoDB/API/VK и я хочу получить возможность изменять/показывать их вместе с данными.
Кейс #3
Моя панель администрирования служит ещё и личным кабинетом для клиентов компании и мне хотелось, что бы они видели страницу отображения (А не страницу редактирования) в которой я могу построить график их компании из ClickHouse и вывести общие данные
Кейс #4
Я имею несколько API которые не имеют средств визуального редактирования и хотел бы использовать ORCHID как панель администрирования всех данных API.
В действительности кейсов и запросов намного больше, но так или иначе всё они пересекаются, по этому мы будем решать общие задачи.
UPD:
Пример чернового кода:
Я не стал перечислять все Layouts которые наследуются, они так или иначе повторяются по своей сути с уже присутствующими.
Стоит помнить, что это лишь черновой вариант, который обсуждается. Если у вас есть предложения или замечания, пожалуйста напишите мне, не стоит стеснятся ;)
