Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Ну с этого начинать надо было )
Я по другуму твой интерфейс представлял.
А в чем загвоздка тогда?
сам же описал поведение
При нажатии на кнопку в форме в поле @input type="hidden" name="taks" value=""@ подставляется задача, которая завязана на эту кнопку, потом контроллер вызывает нужный метод! В методе обрабатывается cid[] чекбоксы которые отправляют... потом в цикле проход этих записей и удаление в модели!
Заводишь такой же хидден, и отсылаешь все в сводный метод, где в зависимости от операции дергаешь другой метод. Либо по клику меняшь action форме и самбитишь на нужный роут.
Беда в том что чекбокс должен быть один для каждой записи!
Чекбокс априори не может быть один на три действия, может с радио-группой путаешь?
Если кнопки именно нужны, либо радиогруппу кастомизируешь, делаешь похожей на кнопочки, либо по клику пишешь в hidden действие
Три чекбокса это костыль ещё больше
Абсолютно не костыль, групповая обработка действия
Чекбоксы
<input type="checkbox" name="fav[{{row.id}}]" />
<input type="checkbox" name="delete[{{row.id}}]" />
<input type="checkbox" name="publish[{{row.id}}]" />
отслыаешь все на метод saveList внутри три массива разбираешь
Все прекрасно работает: делаешь миграцию
php artisan make:migration some_name
идешь в нее
в метод up
public function up()
{
Schema::table('users', function (Blueprint $table) {
$table->string('new_column');
});
}делаешь php artisan migrate
Сид то зачем? Делаешь добавление колонки и все
Schema::table('users', function (Blueprint $table) {
$table->string('new_column');
});
А где вы вообще такой роутинг откопали? Не вижу примеров такого роутинга в документации даже по 4.2
Насчет обратной совместимости они не особо парятся ))
В этом есть свои плюсы, не тянут старое наследие, как некоторые.
Обычно все шаги по апгрейду описаны
https://laravel.com/docs/5.2/upgrade
Слишком никая активность.
Смысл тогда сайт держать? тем более ларавель-энтузиастом, я так понял, ты не являешься...
Продай домен ) Попробую популяризировать ларавел в России.
Я не нашел сначала как это использовать
вот оно оказывается как, можно имя гарда указывать явно
Accessing Specific Guard Instances
You may specify which guard instance you would like to utilize using the guard method on the Auth facade. This allows you to manage authentication for separate parts of your application using entirely separate authenticatable models or user tables.
The guard name passed to the guard method should correspond to one of the guards configured in your auth.php configuration file:
if (Auth::guard('admin')->attempt($credentials)) {
//
}Ну, если желание настойчивое - в 5.2 же есть поддержка разных реализаций Auth одновременно.
Это как делается? что-то в доках не нашел
А чо похоже. В Yii2 есть кстате joinWith и просто with, точно не помню, но вроде with работает с WHERE IN, ну а joinWitch собственно джоинит.
И еще момент с where, сам where перебивает предыдущие where, таким образом он может быть только один, для условий есть andWhere. В laravel можно использовать несколько where ? Он поймет, что имеется ввиду andWhere ?
Да напарывался уже ) по привычке делал в уии ->where()->where()
where в ларе это и есть AND
Я в yii почти никогда не использовал \Yii :: $app->db->createCommand()->queryAll(), там очень удобный AR,
AR не всегда нужен, особенно на разных фоновых рутинах со сложными запросами
Эта тема походу уже за рамками вопроса, пора открывать новую.
Надо ее просто в "болталку" переменовать )
$model = Organization::find() ->andWhere(['alias' => $alias]) ->joinWith(['user' => function ($query) { $query->status(User::STATUS_ACTIVE); $query->joinWith('profile'); }])->one();
Наверное так, если я верно понял структуру
$model = Organization::where('alias',$alias)
->with(['user.profile' => function ($query) {
$query->where('user.status', User::STATUS_ACTIVE);
}])->first();Или так
$model = Organization::where('alias',$alias)
->with('user' => function ($query) {
$query->where('status', User::STATUS_ACTIVE);
$query->with('profile');
}])->first();Честно говоря, пока в реале не использовал выборки со вложенные релейшенами. Не было такой задачи
По мне так удобнее дернуть фасад
Например
\DB::
нежели
\Yii :: $app->db
Ну а к вопросу об удобстве именования
\DB::select() VS \Yii :: $app->db->createCommand()->queryAll()
Хотя по сути, все дело привычки )
В yii2 там есть модульность. Сам класс приложение унаследован от модуля. И можно разбивать как угодно и строить свой каркас приложения.
А почем вы выбрали твиг в качестве шаблонизатора вместо дефолтного ?
И как Вам вообще laravel ? Честно говоря меня очень сильно напрягают фасады, которые я в нем увидел.
С твигом давно работаем, нравится всем. Смысла отказываться нет.
С ларавелем два года, с зачатков пятерки, нравится почти всем ) Вошел как родной, хотя до него работал много лет только либо Limb либо с собственными разработками.
Сейчас новый проект решили для самообразования пилить на YII2, вот он после лары довольно убог. Первую неделю обплевались, поделуха-поделухой )) Сейчас попривыкли. Но юзаем тоже с твигом, хотя поддержка его довольно убогая (или не разобрались еще)
Единственное, что пока понравилось больше в уии - это организация логгирования.
Довольно странный фреймворк, если ларавель старается быть как можно абстрактнее, все специфичные вещи выкидываются (как тот же HTML или Form), то в УИИ они наоборот все тянут внутрь, что дает много полезных инструментов безусловно, но обязан ты их использовать так а не иначе.
Я, например, почти час убил, пока научился делать load из реквеста в модель, даже знакомый уиист не смог помочь. Оказалось, что по дефолту там везде ожидается многомерный массив, ключи - имена модели ))
А чем фасады напрягают?
Кстати, при желании раскидать именно так не вижу проблем, модели будут и так жить где скажете
Роутинг настроить на нужные контроллеры элементарно
Резолвинг пути ко вьюхам тоже, мы правда твиг юзаем через twigbridge. В нем вообще свой неймспейс определить на каждый "модуль"/папку
VitalN пишет:Не понимаю, зачем смешивать модели с вьюхами и контроллерами..
Для удобства, чтобы все было не разбросано по проекту, а в одном конкретном месте.
Это дело привычки просто.
models/category/* VS category/models/*
и views/category/* VS category/views/*
Те же яйца, только в профиль )
А в УИИ разве можно такую структуру "модульную" настроить?
Часть для сайта, часть для админки и общая часть. И так для почти любого модуля. Хранить 500 моделей в одной папке не очень весело. Тоже касается контроллеров и других штук.
А что мешает просто структуру папок сделать нормальную?
Не понимаю, зачем смешивать модели с вьюхами и контроллерами..
models/Company/Company.php
CompanyOtherClass.php
models/SomeOtherStuff/Stuff.php
StuffOtherClass.php
и также для вьюх и контролеров?
И ради любопытства. что за проект такой с 500 моделями?
Насчитал у себя в самом монстровом и старинном проекте 183 шт, живут кстати в одной папке (исторически так сложилось) Неудобств при этом я лично не испытываю, если бы с нуля проектировал сегодня, побил бы наверное на папки по смежным зонам ответственности.
А зачем это? какой-то джумла-стайл?
Сейчас принято отдельные "модули" оформлять в виде composer package
При условии, что это реально отдельные пакеты, которые могут быть переиспользованы в других проектах.
Концепция с разными таблицами неверна. Делайте одну таблицу, заводит либо роли пользователя, либо просто признак того что пользователь админ. Для админки делаете мидлваре, в нем проверяете права.
$user->posts()->paginate(15)
https://laravel.com/docs/5.2/eloquent-r … -relations
storage/framework/*
Делаю
RoutesRoute::controller('/akp', 'AkpController'); Route::group(['middleware' => ['web']], function () { Route::any('/', ['as' => 'main', function() { //session()->flash('status', 'default'); return view('index'); }]); });
Ты вынес за пределы группы с web мидлваре, зачем?
я же показал выше как надо
Прямо смежная тема )
так сделай
/*
|--------------------------------------------------------------------------
| Application Routes
|--------------------------------------------------------------------------
|
| This route group applies the "web" middleware group to every route
| it contains. The "web" middleware group is defined in your HTTP
| kernel and includes session state, CSRF protection, and more.
|
*/Route::group(['middleware' => ['web']], function () {
Route::any('/', ['as' => 'main', function(){
//session('status');
return view('index');
}]);Route::controller('/akp', 'AkpController');
});
Подробнее например здесь
https://mattstauffer.co/blog/middleware … s-from-5.1
Тоже самое.
Тогда перечитай сообщение #5
Ты чего сделать то пытаешься? Почему не используешь рекомендованный самим автором фреймворка путь?
/*
|--------------------------------------------------------------------------
| Application Routes
|--------------------------------------------------------------------------
|
| This route group applies the "web" middleware group to every route
| it contains. The "web" middleware group is defined in your HTTP
| kernel and includes session state, CSRF protection, and more.
|
*/
Route::group(['middleware' => ['web']], function () {
//
});
Если ты считаешь, что знаешь уже достаточно. То сделай нормальный свой middleware, в котором все это будет: session state, CSRF protection, and more.
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)
