Роман Сохарев greabock

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

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

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

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

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

спасибо @lynicidn

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

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

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

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

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

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

Добра!

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

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

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

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

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

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

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

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

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

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

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

	<?php

	namespace App\Backend\Http\Datatables;

	use Datatables;

	abstract class AbstractTable
	{
	/**
	* @var Builder

	<?php

	namespace App\Services;

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


	class Mapper

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

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


	class ExceptionHandler extends Handler
	{

	@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>