З
как вывести дерево категорий в разных вьюшках ?
Size: a a a
2020 March 26
З
например если дочерняя категория имеет связь с другой таблицей
D
а кто-то покупал лицензию на мускуль?)
D
читаю его лицензирование, хочешь коммерческий проект без GPL - покупай ключ..
VY
а кто-то покупал лицензию на мускуль?)
Это сюрприз...
F
validator() функции это из коробки?
M
да.
почитай документацию на laravel.su
почитай документацию на laravel.su
АИ
Всем привет, возможно не по месту вопрос , как откатить версию компонента который подтягивается композером , стоит последняя а мне нужна предыдущая
ВС
Понижаешь версию того пакета, который тянет зависимость.
composer update <vendor/package> --prefer-stable --with-dependenciesАИ
В корневом файле проекта ?
EG
В корневом файле проекта ?
нет сделай
composer require <vendor/package>:version
где version нужная версия
composer require <vendor/package>:version
где version нужная версия
S
смотри отдельный курс по rest api и отдельно по vue, смешивание фронта и бэка до добра не доводит
В том и прикол. Получается ты вообще забываешь про Лару и юзаешь её только как api. А смысл тогда вообще юзать Лару, можно найти с меньшими зависимостями.
МК
Привет, ребята!
Подскажите, пожалуйста, как вы реализуете фабрики (factories) для моделей, которые нельзя генерировать рандомно?
Образно говоря, есть модель "Тип события" (EventType) и оно может принимать три строго определенных значения: "СМС", "Звонок", "Письмо". При этом в тестах мне нужно возвращать через фабрику данные объекты.
Я поступил следующим образом: перед каждым тестом вызываю проверку наличия связанных сущностей для модели "Событие":
(EventType::all()->count() <= 0)
и если типов в БД еще нет, то вызываю сидинг:
\Artisan::call('db:seed', array('--class'=>'EventTypeTableSeeder'));
Все работает. Но выглядит как то некрасиво. + тест генерирует больше побочных эффектов, чем хотелось бы. Подозреваю, что Laravel может поддерживать более красивый подход.
Подскажите, пожалуйста, как вы поступаете, когда в тестах нужно вернуть экземляры моделей, для которых невозможно написать фабрики, генерирующие случайные данные?
Подскажите, пожалуйста, как вы реализуете фабрики (factories) для моделей, которые нельзя генерировать рандомно?
Образно говоря, есть модель "Тип события" (EventType) и оно может принимать три строго определенных значения: "СМС", "Звонок", "Письмо". При этом в тестах мне нужно возвращать через фабрику данные объекты.
Я поступил следующим образом: перед каждым тестом вызываю проверку наличия связанных сущностей для модели "Событие":
(EventType::all()->count() <= 0)
и если типов в БД еще нет, то вызываю сидинг:
\Artisan::call('db:seed', array('--class'=>'EventTypeTableSeeder'));
Все работает. Но выглядит как то некрасиво. + тест генерирует больше побочных эффектов, чем хотелось бы. Подозреваю, что Laravel может поддерживать более красивый подход.
Подскажите, пожалуйста, как вы поступаете, когда в тестах нужно вернуть экземляры моделей, для которых невозможно написать фабрики, генерирующие случайные данные?
P
В том и прикол. Получается ты вообще забываешь про Лару и юзаешь её только как api. А смысл тогда вообще юзать Лару, можно найти с меньшими зависимостями.
а как в spa ее юзать не как апи?
EG
В том и прикол. Получается ты вообще забываешь про Лару и юзаешь её только как api. А смысл тогда вообще юзать Лару, можно найти с меньшими зависимостями.
можно, вопрос зачем, а плюшки, которые предвносит laravel также будут доступны?
в данный момент даже не могу припомнить, а что у нас есть для api backend легковесное и такое же удобное
в данный момент даже не могу припомнить, а что у нас есть для api backend легковесное и такое же удобное
P
типа js что бы генерировало в контроллерах?
И
Привет, ребята!
Подскажите, пожалуйста, как вы реализуете фабрики (factories) для моделей, которые нельзя генерировать рандомно?
Образно говоря, есть модель "Тип события" (EventType) и оно может принимать три строго определенных значения: "СМС", "Звонок", "Письмо". При этом в тестах мне нужно возвращать через фабрику данные объекты.
Я поступил следующим образом: перед каждым тестом вызываю проверку наличия связанных сущностей для модели "Событие":
(EventType::all()->count() <= 0)
и если типов в БД еще нет, то вызываю сидинг:
\Artisan::call('db:seed', array('--class'=>'EventTypeTableSeeder'));
Все работает. Но выглядит как то некрасиво. + тест генерирует больше побочных эффектов, чем хотелось бы. Подозреваю, что Laravel может поддерживать более красивый подход.
Подскажите, пожалуйста, как вы поступаете, когда в тестах нужно вернуть экземляры моделей, для которых невозможно написать фабрики, генерирующие случайные данные?
Подскажите, пожалуйста, как вы реализуете фабрики (factories) для моделей, которые нельзя генерировать рандомно?
Образно говоря, есть модель "Тип события" (EventType) и оно может принимать три строго определенных значения: "СМС", "Звонок", "Письмо". При этом в тестах мне нужно возвращать через фабрику данные объекты.
Я поступил следующим образом: перед каждым тестом вызываю проверку наличия связанных сущностей для модели "Событие":
(EventType::all()->count() <= 0)
и если типов в БД еще нет, то вызываю сидинг:
\Artisan::call('db:seed', array('--class'=>'EventTypeTableSeeder'));
Все работает. Но выглядит как то некрасиво. + тест генерирует больше побочных эффектов, чем хотелось бы. Подозреваю, что Laravel может поддерживать более красивый подход.
Подскажите, пожалуйста, как вы поступаете, когда в тестах нужно вернуть экземляры моделей, для которых невозможно написать фабрики, генерирующие случайные данные?
'type' => $faker->randomElement([Payment::TYPE_YANDEX, Payment::TYPE_WEBMONEY]),
И
если что-то сложное - ты можешь определить какие-то значения до фабрики, а потом это использовать в ней