Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Если пролистнете контроллер вниз, есть там такое?
protected function validator(array $data) {
return Validator::make($data, [
'name' => 'required|max:255',
'email' => 'required|email|max:255|unique:users',
'password' => 'required|min:6|confirmed',
]);
}Эта функция вызывается в register()
$this->validator($request->all())->validate();А зачем изворачиваться? Что, собственно, не устраивает?
Здравствуйте.
Все сохраняется, роли можно менять, удалять. В базе все отображается как должно.
Только не работает все равно. Работает только если поменять в laratrust_seeder и перезапустить db:seed.
Вы не могли бы объяснить, что имеется ввиду? "Все нормально, но... не работает" :-)
"Когда меня спрашивают для чего нужны сервис-провайдеры в Laravel, я пожимаю плечами и говорю: если вы не знаете зачем они нужны, значит они вам не нужны. Если вы пишите и строите код так, как это описано во всех мануалах, скорее всего вам хватит одного провайдера на всё приложение, и он уже есть сразу. И не надо парить мозг себе и людям. Просто забейте на это все." (C)
В конфиге так:
'AdminDisplay' => SleepingOwl\Admin\Facades\Display::class,
Это там: /vendor/laravelrus/sleepingowl
А use в конфигурации модели НЕ через сервис провайдер:
use SleepingOwl\Admin\Model\ModelConfiguration;
Пора б уже опуститься с детских качелей на асфальт.
Максимум люди могу направить в нужное русло, но работу, за которую ты получшь деньги, за тебя никто делать не будет. Разве, что дураки, не в обиду дуракам сказано.
И кодом в тебя (на форумах, в частности на этом) готовым бросят лишь в том случае, если это займёт не больше 5-10 минут. Либо те, кому делать нечего на данный момент.
Так что привыкай, что тебе подскажут куда думать, но не готовую работу.
Да ладно! Где я здесь спрашивал про "что-то готовенькое", что требовало больше тех самых 5-10 минут? Только покажи конкретно, по-мужски. Про обновление версий что-ли? Вопрос общего плана, не более. Я тебе, на примере Ubuntu, в пять предложений ответ расписал, притом исчерпывающий. А от тебя ничего, кроме многозначительных намеков, но я тебе и за это говорю - спасибо. И ладно бы, все на этом, но теперь ты еще "жить учишь". А вот этого, веришь, мне от тебя совсем не нужно.
Издеваешься помаленьку? :-)
Ладно, понял я примерно, что к чему, остальное, как говорится, в процессе. Спасибо :-)
Новые проекты лучше начинать на крайних версиях, обновляя до выхода LTS а потом - до следующей LTS? Как-то так?
В том то и дело, что ответов нет.
К примеру, тот же Ubuntu - там все понятно.
Если ты устанавливаешь систему где-нибудь в фирме, или кому-нибудь, кто настроен только на стабильную работу - ставь крайнюю LTS и не парься. Будет стабильность, а с новыми плюшками может случиться напряженка.
А самому себе, если ты "в душе исследователь", ставь крайнюю версию и меняй на новую, едва релиз появится. Будут "детские болезни" и плюшки, но тебя-то это устраивает, потому что - прикольно :-)
Короче, ясно, из чего выбирать.
Отсюда и вопрос, какова стратегия Laravel в этом смысле?
Я пока не могу этого понять, вот и спрашиваю. Если ты считаешь, что ответил, прекратим разговор.
Да много есть замечательных принципов. По своему, глубоко личному, опыту могу сказать, что практически невозможно, вот так вот, сходу, действовать оптимально, особенно, если знаний еще только предстоит набираться. Это всего касается. Ну и какой смысл в префекционизме? Перед Вами вполне конкретная задача, ну и почему бы не начать решать, зачем подстраиваться под какие-то принципы?
На laravel.su есть документация - там два быстрых старта, для начинающих и продвинутых. Если прочли Мэтта Зандстру, то для продвинутых должен быть понятен. Там, по-сути, весь цикл разработки представлен. Ссылку на статью про отношения я Вам дал.
Извините, но больше не имею возможности на данную тему дискутировать.
Да какие утверждения, просто спросил.
Ладно, тогда так сформулирую.
Ты пишешь, что сейчас переход с 4 на 5 дорого обойдется. Допустим.
А что можно было сделать, чтобы этого избежать? А самое главное, надо ли делать? Какой логикой руководствоваться?
Иначе говоря, когда есть смысл думать об обновлении? И когда это противопоказано? Вот я к чему веду.
Ты пишешь "обновляться необходимо по причине удорожания стоимости поддержки в случае пропуска этой версии"
А как определить, увеличится ли стоимость поддержки при переходе на другую версию?
Мне кажется, для этого исключение должно быть перехвачено, нет?
Ну, зачем огород городить? :-)
Думаю, обсуждать "мы хотим работать с этими публикациями через один интерфейс", смысла нет. Лично я, наоборот, хотел бы работать с ними в разных интерфейсах, ведь новости - это новости, статьи - статьи, а объявления - это объявления. Ну, есть у них одинаковые атрибуты, и что? :-)
Короче, спорный вопрос.
Как я бы предложил сделать.
Сначала про данные.
В Laravel модели наследуются от класса Model, в котором уже весь базовый функционал присутствует - удаление, обновление, создание, и ничего своего здесь особо придумывать не нужно. Каждому объекту этого класса в БД соответствует одна таблица. Поэтому, я так понимаю, делать один общий класс для всех трех сущностей имеет смысл только в том случае, если Вы хотите работать с одной и той же моделью. Смотрите сами, я бы не стал. Сделал бы три отдельных класса, с присущими им свойствами. А иерархия классов, про которую Вы пишете, считаю, лишняя. В Laravel это не нужно.
Далее нужно будет сделать вывод новостной ленты - это контроллер и представление. Вот в контроллере-то Вы и пропишете получение данных из всех трех моделей, а результат, там же, передадите представлению. Техника описана в документации и статьях, например, Все об отношениях в Laravel 5
Я бы сделал так. Конечно, могу ошибаться, потому что сам в этой теме недавно.
Считаю, что по вопросу высказался.
То есть обновляться с выходом каждой новой версии фреймворка, при условии, что она поддерживает текущую версия php?
руками выгружаешь голый фв, и переносишь бизнес-логику (всё написанное руками) в новыую версию. правишь баги, выглаживаешь углы. это работа, мужик. тут ничего само собой не происходит.
Друже, я не про то. Я имел ввиду логику принятия решений по выбору версии для разработки.
С другой стороны, ты прав. Тут никаких 100% быть не может. Ладно, фреймворк, но кто же даст гарантию на корректную работу пакета, той же админки, с новой версией?
Но тогда, получается, LTS через пару лет может проиграть во многом, так? Например, появятся какие-то новые решения, фундаментально-стратегические?
Тогда углубляться не надо пока, иначе придется прорабатывать возникшие вопросы.
А если совсем упростить, то.
Есть запчасти, которые хранятся на складах, так? Нужно сгенерировать запрос, есть ли эта запчасть на конкретном складе, так? Ну, или вообще, где она есть, не важно. Если есть, чего-то там сделать, если нет - сгенерировать документ-перемещение, так?
Маленькие "пять капель".
MVC, по-сути, к предметной области, как к таковой, никакого отношения не имеет, это парадигма программирования. С ней, или без нее, задачи решаются.
Насколько я понимаю, "в разрезе" ничего специально проектировать не нужно, начать следует с описания процессов предметной области.
Есть, к примеру, какой-нибудь ее фрагмент, для рассмотрения? Самый простой процесс?
Можно было бы прикинуть.
А уж когда дойдет дело до кода, то вовсе не обязательно использовать весь спектр PHP ООП. Ну, к чему, например, объявлять абстрактный класс, если задача тривиальна а пишете на фреймворке? :-) Там "все украдено до нас" :-)
будь мужиком.
"Настоящий мужчина должен поставить себе UNIX!" (С) :-)
А если серьезно, для меня стратегия поддержки версий Laravel тоже момент не очевидный. А уж сова...
Помню, ее на 5.2 пришлось "с бубном" устанавливать. Правда, надо сказать, они довольно оперативно адаптировали этот момент.
Я правильно понимаю, что сейчас таки лучше работать с 5.3 с тем, чтобы, как придет время, обновиться до LTS 5.4 и уже не дергаться?
Может, посоветуешь ходы более-менее оптимальные?
Ну так в чем проблема? Если хотите "понимать, как оно работает" и "использовать максимально все возможности", нужно глубокое понимание основ. А если этого нет, то "использовать максимально все возможности" даже на CMS не получится. Но работать можно.
Прочтите книжку Мэтта Зандстры. После, примерно, 80-й страницы, вопросы про сервис-контейнер и репозиторий (лично я так думаю! :-)), отпадут.
Есть документация для 5.2 на laravel.su - точно.
Возможно, и для 5.3 на github, хотя гайды вряд-ли успели перевести.
А что касается уверенного использования в работе, то, я думаю, можно и не читать про сервис-контейнеры. Вы же сами "полезли" на этот уровень.
Вы имеете ввиду перевод гайда для продвинутых? На самом деле, там все более-менее ясно, если только есть понимание ООП. Лучше всего, пожалуй, Мэтт Зандстра подойдет, в сети скачать можно без проблем. И это, я сам новичок, если что :-)
Вот я еще где менял, в миддлваре guest.
if (Auth::guard($guard)->check()) {
return redirect('/home');А если поиском по проекту пройтись, по $redirectTo = '/home' или даже лучше просто '/home'?
Кажется, если в каких-то контроллерах это явно не указано, он от какого-то родителя наследует.
С другой-то стороны, так уж плохо, что он в контроллерах позволяет этим свойством рулить? Можно редиректить в зависимости от ситуации. Или что-то не так?
Большое спасибо! Роль одна.
Доброго времени суток!
В контроллере, вроде бы, отрабатывает корректно:
$users = User::with(['roles' => function ($query) {
$query->where('roles.name', '!=', 'testban');
}])->get();
return view('users.index', ['users' => $users]);Не получается вывести роль в blade, никто не подскажет, как это сделать, как ее из $users вытащить?
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)