Какой, по-вашему, самый ужасный и скучный этап в создании сайта на PHP? По-моему — это создание админки. Все эти однообразные формы, таблицы, большое количество практически одинаковых файлов, которое нужно не только создать, но впоследствии и обслуживать. Поэтому под каждый используемый мной фреймворк рано или поздно я создавал набор классов, облегчающих этот процесс.
И вот я добрался до Laravel. Представляю вам пакет, который поможет достаточно быстро создать админку и больше времени уделить фронтэнду.
Вы спросите, что же в моем «велосипеде» заставило меня опубликовать его на всеобщее обозрение? Для меня это его несколько сильных сторон:
В-нулевых, он помогает мне в реальных проектах. Возможно, поможет кому-нибудь еще, а это уже значит, что все было сделано не зря.
Во-первых, конфигурационные файлы.
Я устал от конфигов, которые представляют из себя магическим образом созданный массив, в котором есть ключи с определенными названиями и текстовые значения этих ключей. Никакой вам помощи от IDE с автоподстановкой или подсветкой неверно указанных значений найти в коде проекта, где конкретно обрабатывается определенный ключ из конфига и что он делает — далеко не тривиальная задача. Да к тому же код пакета вам тут слабый помощник, документация — единственный ваш друг.
Поэтому я отказался от конфигов в виде массивов (php-массивов, yaml-файлов, неважно) и пришел к конфигам в виде php-кода. Вот вам небольшой пример описания модели «Country» из демо-приложения для использования в админке.
Admin::model('Country')->title('Countries')->with('contacts')->columns(function ()
{
Column::string('title', 'Title');
Column::count('contacts', 'Contacts')->append(Column::filter('country_id')->model('Contact'));
})->form(function ()
{
FormItem::text('title', 'Title');
});
Не знаю, как вам, а мне кажется это намного более удобным для чтения, нежели массив с ключами, хотя по сути содержит всю ту же информацию.
Несколько плюсов данного подхода:
- Ваша IDE будет знать контекст выполнения этого кода и сможет вам подсказывать, какие типы столбцов или элементов формы существуют и какие дополнительные параметры принимает конкретный элемент;
- Опечатка в названии «ключа» автоматически приведет к ошибке, которую конфиг на массиве не сможет предоставить;
- Парсить массив, содержащий столько информации, не самая приятная задача. Тут же ее просто не существует, в результате чего код становится чище.
Во-вторых, расширяемость.
Вы можете регистрировать свои собственные типы столбцов и элементы формы, которые впоследствии будут использованы в ваших моделях. Поэтому вы не ограничены исключительно тем функционалом, который создал я.
Также вы можете регистрировать свои собственные контроллеры для обработки определенных пунктов меню — и тут вы уже ничем не ограничены.
В-третьих, количество работы, которую необходимо проделать для создания админки.
Вам будет необходимо создать меню, а также создать описание каждой модели, для которой нужно создать админку. И это все.
Я создавал этот пакет для использования преимущественно в небольших проектах, имеющих множество слабо связанных между собой моделей. Как правило, основная их цель — отобразить данные во фронтэнде в соответствии с дизайном, а какая уж там будет админка заказчику не так важно, лишь бы выполняла основную цель — управление содержимым сайта.
исходники на GitHub | документация проекта| демо приложение
Автор: sleeping-owl
