greabock

#Создание пакета для Laravel 4 это перевод оригинальной статьи, без претензии на литературность. ##Вступление Одна из лучших вещей в Laravel 4 - это то, как он полностью выстроен вокруг идеи совместимости. Долгое время, в РНР-проектах было довольно трудно управлять зависимостями. Копирование и вставка кода в проект - это кошмар. А поддерживать компоненты в актуальном (up-to-date) состоянии, при таком подходе - очень сложно. Далеко не все разработчики использовали PEAR в своих проектах, а потому, в конечном итоге, с каждым новым проектом приходилось изобретать свой велосипед, вместо готовых решений предоставленных Сообществом.

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

Однако с ростом популярности Composer, PHP (наконец-то) имеет свой менеджер пакетов, который призван решить данную проблему.

greabock

#Волшебный Eloquent. ##Дисклеймер Данный материал абсолютно не претендует на уникальность, и не является попыткой открыть для кого-то Америку. Все ниже изложенное (прямо или косвенно) можно легко почерпнуть из официального мануала. А для чего же оно тогда написано? Попытка подать информацию в чуть более развернутом виде, систематезировать собственные знания, и снять острый приступ графоманства. Если это вдруг окажется кому-то полезным, то мне будет приятно.

##Введение TL;DR
Так уж сложилось, что слоняясь по "интернетам", в поисках сообщников в ограблении банка единомышленников в изучении framework'a Laravel, я забрел в чат хоть и праздно прозябающего, но (стараниями Алексея) живого и дружелюбного Cообщества, и плотно там осел. А через какое-то время заметил, что отвечаю на чьи-то вопросы гораздо чаще, чем задаю их. Хотя мой замысел был иной: изначально, я хотел добраться до "знающих людей" и, как вампир, высосать через чат все и

greabock

#Волшебный Eloquent

И снова здравствуйте! Помните я говорил, что хочу рассказать в следющей статье о выборке данных? Так вот - я соврал. Нет, я по-прежнему хочу рассказать о практической работе с моделями... но люди из нашего дружного чата убедили меня, что пока еще рано и тема сисек стрктур данных раскрыта не доконца. А ведь все мы прекрасно знаем, как (до зуда в пятой точке) неприятно, когда остается некая недосказанность...

Итак... Я все же засскажу о выборке, но касаться это будет древовидных структур.

##Часть вторая."Ландшафтный Дизайн" или "Будни Садовода"

greabock

<?php

use Illuminate\Database\Eloquent\Model;

class Seo extends Model {
  
	protected $table = 'seo';
  
	public function material()
	{

greabock

Уже был тут? Может ты вторую часть искал?

---

Former - это название небольшого проекта, который я хочу тебе показать. Садись поближе, сейчас начнется...
Так вот, Former - это такой хитрый пакет PHP, который позволяет делать всевозможные манипуляции с формами, и он очень удобный в использовании. Да и вообще он крутой чувак, если узнать его поближе.

Former пережуёт все и положит тебе прямо в рот - он обработает за тебя и отвалидирует ввод, автоматически сгруппирует поля, отловит отчет об ошибке, и даже создаст разметку для твоего любимого css-фрейма (Bootstrap, Foundation). Ну а что бы узнать больше, я предлагаю тебе ознакомится со всеми, описанными ниже, фишками.

greabock

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

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

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

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

greabock

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

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

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

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

greabock

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

Добра!

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

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

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

greabock

---

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

---

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

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

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

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>