Моя сборка для разработки Laravel проектов

Приветствую! Хочу рассказать о моих “подготовительных работах” перед реализацией Laravel проектов. Здесь я изложу и кратко опишу почему использую некоторые пакеты. Некоторые я использую во всех проектах, другие – когда сочту нужным. Эта статья – мой личный опыт, может кто-нибудь знает лучшие альтернативы или что еще нужно для более удобной разработки – пишите в комментах – будем благодарны(я и читатели блога). В любом случаи эта статья будет полезна новичкам в данном фреймворке. Погнали!11

Debugbar for Laravel

Этот пакет нужен исключительно для удобства разработки(именно удобства тк я обходился без него поначалу). После его установки, при условии что в .env-файле

APP_DEBUG=true

внизу страницы будет панель

Debugbar for Laravel
debug-bar

с информацией об ошибках, шаблонах, роуте и тд… Также, при помощи фасада Log можно писать собственную инфу в панель. И что не мало важно – она отображает и ajax(к API) запросы.

IDE Helper Generator for Laravel

Еще один пакет, того же автора, предназначенный для удобства и скорости разработки. Он генерирует phpDocs, которые анализируются IDE и видны в виде подсказок, что позволяет избежать опечаток и постоянной инспекции других классов. Работает для моделей и фасадов. Прежде чем генерировать доки для моделей, нужно настроить связь с БД и иметь соответствующие таблицы.

Associate users with permissions and roles

Ни одного проекта без разделения но ролям я еще не делал и этот пакет делает это – позволяет пользователю дать роль.

Associate users with permissions and roles
permissions and roles

Эта зависимость содержит возможности создавать роли, давать права а также содержит мидлвары(что это – расскажу позже, но очень важная и крутая вещь). Даже если рядовому пользователю не нужно регистрироваться на сайте, все равно а сайте всегда есть админка с супер-админами, менеджерами и тд.

Laravel-Modules

Пакет, который я не везде использую, но в проектах он помогает организовать модульную архитектуру. Он содержит команды создающие набор папок и файлов(по структуре подобных к структeре каталога app). Как по мне базовая архитектура лучше всех, однако если над проектом работает команда – проекты с базовой превращаются в адок. Обьяснение почему я недолюбливаю модульность: допустим ,есть модуль Account на лице сайта, который имеет модель User; есть модуль Admin, где также есть модель User. Вопрос: как поступить – дублировать код(тк поля почти идентичны), делать общие трейты и фасады или вне модулей делать абстрактную модель User, и наследоваться от нее(нарушая идею модульности в моем понимании)? Возможно , я еще не достаточно опытен и чего то не понимаю, но в базовом исполнении, прибегая к использованию лара-фасадов таких дилемм не возникает.

Easy AdminLTE integration with Laravel

Небольшой пакет для построения админ-панели, содержащий набор шаблонов и стилей, основанных на Bootstrap css. Код самых виджетов можно глянуть в AdminLTE Demo.

Заключение

Это все рекомендации, однако они, я уверен, сделают разработку, и что важнее, развитие проекта проще , быстрее и понятнее…

Namespace на пальцах

Всем привет и здравствуйте! Сегодня речь пойдет об пространстве имен(nаmespaсe). Эта фича чисто объектно-ориентированного программирования; несмотря на то, что пространство имен есть во многих языках программирования(C++, python, java и т.д.), код, приведенный в примерах, будет на php.

Содержание

Теория о nаmespase

Пространство имён (англ. namespace) — некоторое множество, под которым подразумевается модель, абстрактное хранилище или окружение, созданное для логической группировки уникальных идентификаторов (то есть имён).

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

Такое определение дает нам википедия, однако оно, как по мне, достаточно сложное для понимания. Я же определю более просто – это дополнительная координата для обращения к классу. Рассмотрим примеры для большего понимания…

Примеры

Для начала, приведу жизненный пример. Допустим есть группа людей в которой есть несколько человек с одним и тем же именем(Иван). Третий, из этой группы, обращается к Ивану и те не понимают к какому. Так вот, их фамилия и отчество(или еще какие-то координаты) как раз и будут их пространством имен.

Теперь применительно к коду: 2 программиста написали по одинаково названному классу

<?php
class ClassName {
    // some methods
}

и отправили третьему. Тот, должен использовать эти классы для сборки приложения – но как к ним обращаться? Вариант №1 – на берегу договориться о наименовании классов – это подойдет для небольшого их количества, но если их десятки и сотни? Вариант №2 -правильный вариант – договориться об использовании пространств имен

<?php
namespace developer1;

class ClassName {
    // some methods
}
<?php
namespace developer2;

class ClassName {
    // some methods
}

вот так это будет выглядеть в php. Далее, третьему нужно использовать эти классы в своем коде. Чтоб обратиться к такому классу, нужно сначала указать пространство имен, а затем имя класса

<?php
$var1 = new developer1ClassName();
$var2 = new developer2ClassName();

это годится при единичном вызове каждого класса, но что если ссылок на каждый класс множество? каждый раз писать пространство имени класса? По меньшей мере, это не удобно. Для этого есть директива use as (для php, в других языках есть аналоги)

<?php
use developer1ClassName as ClassName1;
use developer2ClassName as ClassName2;

$var1 = new ClassName1();
$var2 = new ClassName2();

По сути, это работает как “локальное переименование”, т.е классы ClassName1 и ClassName2 будут существовать только в пределах файла с этими директивами. В случаи если начальные классы имеют разные названия, директиву use as можно сократить до use

<?php
use developer1ClassName;

$var = new ClassName();

Работать это будет так: при обращении к классу ClassName будет проверены все директивы use и если есть та, которая на конце имеет такое же имя класса, будет обращение к пространству этого имени.

Автозагрузка классов

Обычно, чтоб получить доступ к файлу, используют функцию на подобие require(), применяя ее к каждому файлу. Когда проект большой и требует подключения множества файлов, а также написан с соблюдением принципов ООП(что в нынешних реалиях маст хэв,

пьяная плесень - монгольский

т.е. обязательно) это неудобно. В этом случаи удобно использовать “автозагрузку классов”. Дело в том, что при обращении к незнакомому классу, возбуждается функция, которой передается название требуемого класса(если известно его имя пространства – будет передано и оно).

Таким образом, объявив эту функцию раньше вызова неизвестного класса, можно подключить ее файл. Реализую это на php.

Сначала приведем структуру директорий и названий классов в соответствие с namespace и именем класса. Есть две функции для подобной работы – __autoload()(устаревшая с php 7.2) и spl_autoload_register()(появившаяся в php 5.0). Также, с php 5.3 добавлены анонимные функции и код автозагрузчика будет выглядеть так

<?php
spl_autoload_register(function($class)
{
  require($class . '.php');
});

Использование анонимной функции необязательно, можно, как аргумент, указать имя функции-загрузчика.

Заключение

В этой, сравнительно небольшой, статье рассмотрены пространства имен для классов. Наведены 2 способа их использования и, несмотря на то, что код приведен лишь для языка php, для других – эти принципы работы, также, сохраняются.