Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Так и думал — у Вас же ID в URL, не в параметрах.
Входные параметры (массив $request->all()) по определению — это GET/POST параметры (то что идет после? в адресе).
Параметр, замаскированный в URL — это не параметр GET, строго говоря.
Laravel такие значения вставляет в объект $request (что Вы уже и так нашли), еще они доступны как $request->route(’id’).
Валидировать можно в методе authorize() в созданном классе запроса. Можно сделать проверку is_int(), можно проверить есть ли права у юзера.
’required’ — бессмысленно проверять, раз юзер сюда попал по маршруту — значит ID указан. Иначе бы не сработал маршрут 
Покажите route? Каким образом ID передается — как query параметр, или как часть URL?
Валидировать самый простой способ — сделать кастомный запрос php artisan make:request, заменить Request $request на этот новый класс, а там внутри класса Вам Laravel создаст метод rules() — там будут правила для валидатора
Или каждый маршрут или один RESTful ресурс (Route::resource).
Идея основная в том, что файл routes.php должен служить некоей документацией — программист открывает этот файл и примерно понимает, что приложение умеет делать, где что искать. Implicit контроллеры делали зло — они прятали от программиста часть информации ради небольшого сохранения времени.
Вам наверное лучше роли, а не модели использовать для этого? Есть готовый package: https://github.com/Zizaco/entrust
Если пользователь реально один и тот же, просто права разные — было бы неправильным с точки зрения архитектуры плодить Active Record модели (Eloquent). Раз юзер один — модель должна быть одна, возможности у нее разные.
Почему вы не хотите просто в модель User добавить методы вроде isZavsklad()? (это если не использовать настоящие роли)
И вообще, судя по описанию вам тут подходит decorator pattern? Реализовать zavsklad/manager как два отдельных не-Eloquent класса, а потом в них wrap’ить оригинальный класс User.
Максимально близкий к оригиналу:
public function store()
{
Post::create([
'title' => Input::get('title'),
'slug' => Input::get('slug'),
'user_id' => Auth::user()->id,
'content' => Input::get('content')
]);
return redirect()->route('post.index');
}
1) Особого смысла в параметрах указывать Post $postModel нет, оно просто делает new Post.
2) В реальности лучше сделать свой класс запроса (php artisan make:request), где будут проверятся все поля типа title, slug и тд. Тогда можно будет вообще создавать одной строкой: Post::create($request->all());
Надо сделать новую миграцию, а не редактировать старую. Либо сделать рефреш всех миграций — тогда это заново запустится (php artisan migrate:refresh --seed)
В принципе, в демо (staging) среде можно просто редактировать оригинальную миграцию и рефрешить. Когда проект будет в production — даже такую мелочь надо будет отдельной миграцией делать со Schema::table(). Метод down() тоже важен — не забывайте откат указывать.
php artisan make:migration add_levelneed_column --table=charCategories
В database/migrations/ появился файл с add_levelneed_column в имени, в нем делаем:
public function up()
{
Schema::table('charCategories', function (Blueprint $table) {
$table->integer('levelNeed')->default('0');
});
}
public function down()
{
Schema::table('charCategories', function (Blueprint $table) {
$table->dropColumn('levelNeed');
});
}
Вообще, по умолчанию Debugbar влючается только если в окружении стоит APP_DEBUG = true, а такое значение - обычно только в staging среде.
Зачем Вам ограничивать работу debugbar по IP на staging сервере? На такой сервер обычно ходит только сам конкретный разработчик.
Если Вы хотите на production сервере запускать debugbar для конкретных IP - можете \Debugbar::enable(); для этого использовать, где-нибудь в routes.php скажем.
app.php точно нельзя трогать - это просто конфиг, там логики не должно быть такой
Этот модуль регистрируется тут:
vendor/laravel/framework/src/Illuminate/Events/EventServiceProvider.php
Что в свою очередь вызывается тут:
vendor/laravel/framework/src/Illuminate/Foundation/Application.php
У вас во втором regexp неэкранированный минус стоит - это означет диапазон всегда. В данном случае от _ до / - такого диапазона не бывает
Попробуйте поставить \ перед -
Создает совсем пустой контроллер, уже не подготавливает "стандартные" методы типа "index", "destroy" и пр. А просто создает файл и класс, даже без индексного. Не думаю, что это критично, но все же решил поделиться.
И да, старый метод все-таки работает на новом, я прошу прощения.
Он по дефолту просто не создает эти RESTful методы. Там надо параметр добавить - и он их создаст
Спасибо, я разобрался. Тут как говориться, выбирай из двух зол меньшее. Писать всё равно придётсья, но одно дело написать новую реализацию интерфейса, а другое перекопать все методы контроллера, которые затронуло изменение.
Вот вот!
Это в английском называтся 'tightly coupled' - тесно связанный код, когда везде используются конкретные классы.
Когда используются только контракты - легко тестировать, легко заменять, легко реализовать модульную структуру и тд.
Это настолько меньшее зло, что почти не зло вообще 
Способов несколько, и насколько я помню - оба упомянутых способа до сих пор действуют
В 5.2 только вынесли все стандартные middleware в группу (по дефолту не загружаются), больше ничего в маршрутизации не менялось
Потому что один кусок кода не знает, что конкретно используется в другом куске кода - разные части приложения общаются на уровне интерфейсов.
Скажем есть класс Webmoney, который реализует онлайн-платежи через Webmoney, и есть контроллер Billing, который на сайте форму платежей и так далее показывает.
Если в контроллере Billing указан абстрактный интерфейс PaymentInterface, а класс Webmoney его реализует - то в будущем перейти на, скажем, Яндекс Деньги будет очень просто - надо будет написать класс Yandex, который будет реализовать тот же контракт PaymentInterface и где-нибудь в Laravel переключить Webmoney на Yandex - и все.
В контроллер ВООБЩЕ не придется заходить.
В реальном проекте - таких зависимостей могут быть десятки, и если все классы и контроллеры явно указывают Webmoney, а начальство скажет "а давай лучше PayPal" - может понадобиться в миллион файлов идти и править. И так каждый раз!
Ну и стоит добавить, что тестировать легче, когда используются контракты. Фейковый класс реализующий узкий набор методов - проще куда подставить.
Тоесть очень большая гибкость, можно собрать что угодно. В случае ларавель, даже с расширением у меня не работает переходы по методам в ide, что очень сильно напрягает.
Опять таки в laravel есть крутые штуки по сравнению с yii2, но в тоже время в yii2 тоже есть очень крутые штуки.
С этим то я согласен. Просто неудачные имена для методов выбраны - это делает код Yii2 менее читаемым.
В Laravel читабельнее код выходит в итоге, на это и акцент (отсюда и популярность частично).
В идеале не нужны комментарии и документация, весь код - как документация.
А вот взять приведенный кусок из Yii:
$model = Organization::find()
->andWhere(['alias' => $alias])
->joinWith(['user' => function ($query) {
$query->status(User::STATUS_ACTIVE);
$query->joinWith('profile');
}])->one();
- Как можно что-то найти без параметров поиска? Feeling lucky, как в Google?
- Как может быть andWhere() сразу после поиска? найти()->иГде()? Бред с лексической точки зрения
- один() - один откуда? случайно, из конца, из начала?
Можно подумать, что это мелочи все - но это очень сильно влияет на читаемость кода
Ну, если желание настойчивое - в 5.2 же есть поддержка разных реализаций Auth одновременно.
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)