greabock

28 мая выходит финальная 4-я версия фреймворка.

Так выглядела первая запись в сообществе в 2013 году. К сожалению, мне не удалось добыть статистику посещаемости группы на тот момент времени. Однако предполагаю, что самые первые посты были "в пустоту". Я восхищаюсь усердием и методичностью Алексея, который уже четыре с лишним года изо дня в день занимается тем, что "доит" старые и находит новые каналы информации по фреймворку.

Через год после создания сообщества в феврале 2014 кому-то из первых (кажется это был @vanchelo) пришла в голову замечательная мысль, что неплохо было бы иметь чатик для обмена опытом в реальном времени. Тогда это было уютненькое место, для нескольких знакомых. Я вырос в этом чате, как программист. Когда я только пришел в чат, я хреначил код в саблайме и не знал, что такое неймспейсы. Там мне объяснили что как устроено и пару раз "ткнули носом" в доку.

greabock

<?php 

namespace App\Backend\Http\Datatables;

use Datatables;

abstract class AbstractTable
{
    /**
     * @var Builder

greabock

<?php

namespace App\Services;

use Doctrine\ORM\EntityManager;
use Doctrine\ORM\Mapping\ClassMetadataInfo as MetaInfo;
use RuntimeException;


class Mapper

greabock

<?php namespace App\Core\Handlers\Exceptions;

use Exception;
use Illuminate\Foundation\Exceptions\Handler;


class ExceptionHandler extends Handler
{

greabock

актуально для версий до коммита от третьего сентября. В версиях новее, это делается приблизительно так:

$mailer->getTransport()->setStreamOptions([#...]);

спасибо @lynicidn

Я уже давно ничего не писал... но наш бессменный лидер - Алексей aka @Butochnikov угрозами и шантажом убедил меня написать хоть небольшую заметку... Держите, други ))

greabock

@extends('backend::layouts.default')
@section('content')
    <div id="users-controller">
        <section class="content">
            <div class="row">
                <div class="col-xs-12">
                    <div class="nav-tabs-custom">
                        <ul class="nav nav-tabs nav-tabs-users">{{-- Start Tabs --}}
                            <li v-class="active: isActive('#users-list')">
                                <a href="#users-list" v-on="click: tabTransition('#users-list', $event)">{{ trans('system.list') }} </a>

greabock

---

Инверсия управления (англ. Inversion of Control, IoC) — важный принцип объектно-ориентированного программирования, используемый для уменьшения зацепления в компьютерных программах. Также архитектурное решение интеграции, упрощающее расширение возможностей системы, при котором контроль над потоком управления программы остаётся за каркасом - ru.wikipedia.org

---

Сегодня хотелось бы поговорить о реализации инверсии управления в Laravel. Это один из самых важных аспектов организации слабой связанности компонентов в любимом нами фреймворке, и его понимание играет ключевую роль при создании качественных пакетов и приложений.

Когда мы говорим об IoC в Laravel, то следует знать, что он стоит на трех китах:

1. Внедрение зависимостей (Dependency Injection)

greabock

Как оставаться упоротым и счастливым

Добра!

Моя прошлая статья по модульной структуре имела некоторый резонанс - были как противники так и сторонники этой методики. Как и в прошлый раз, я подчеркну, что не считаю этот путь единственно верным, и не буду пытаться завлечь кого-то на "темную сторону". Вместо этого, я расскажу вам, как я "живу" с модульной структурой, и как решаю некоторые проблемы.

Модули, как они есть

Прежде всего, хотелось бы вернуться к тому, как устроены модули (они же домены, или области ответственности). В прошлый раз, я говорил о том, что можно просто удалить любой модуль и приложение продолжит свою работу. В действительности, это не совсем так. Дело в том, что модули очень похожи на пакеты composer (собственно ими они и могут являться). Что это значит? Это значит, что модули, подобно пакетам, имеют зависимости. Например, модуль Blog может иметь в зависимостях модуль User - ведь у блога должен быть автор. Модуль

greabock

#Как упороться по модульной структуре и областям ответственности в Laravel. А потом стать счастливым.

[UPD] после пары вопросов в личку, решил добавить дисклеймер: Я не считаю, что это единственно верный путь. Я просто говорю вам о том, что существует такой подход.

Когда меня спрашивают для чего нужны сервис-провайдеры в Laravel, я пожимаю плечами и говорю: если вы не знаете зачем они нужны, значит они вам не нужны. Если вы пишите и строите код так, как это описано во всех мануалах, скорее всего вам хватит одного провайдера на всё приложение, и он уже есть сразу. И не надо парить мозг себе и людям. Просто забейте на это все.

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

greabock

Что, не понял куда ввалился? Ну тогда тебе в первый пост.

##Datalist А что еще он умеет делать? Datalist, он умеет делать Datalist. Ты не знаешь что это? Окааай... знаешь, типа иногда можно дать людям не только выбор из списка, но еще и позволить им ввести что-то в ручную? Вот это и есть datalist. С Former'ом такие вещи делаются на раз-два:

Former::text('clients')->useDatalist($clients)

// Или можно опять опять же подрубить модель как делали с fromQuery()
Former::text('projects')->useDatalist(Project::all(), 'name')