Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Route::resource() нужен, если у вас в приложении есть сущности, которыми удобно управлять по REST-протоколу и во фронте у вас js-фреймворк, который тоже умеет делать REST-запросы (например, ангуляр с рестангуляр-модулем) ИЛИ вы работаете в команде и фронт пишете не вы. В этом случае вы пишете код в рамках этого протокола и у вас отпадает головняк на тему, какие придумывать урлы и как именно общаться одному с другим.
Route::controller() нужен, если вам лень писать роуты для каждого урла и вы принимаете внутреннее ларавеловское соглашение о связи урлов и методов контроллера: /user/profile -> class UserController { function getProfile() } И благодаря этому получаете возможность писать один роут на контроллер вместо нескольких.
Эти вещи сделаны для удобства, если вы сомневаетесь, что они вам нужны - не используйте вовсе. Я, например, решил для себя их не использовать, юзаю только Route::get() и Route::post(). С одной стороны долго писать каждый роут, зато имею полный контроль над происходящим, включая такую замечательную вещь как генерация html-ссылок и редиректов по именам роутов (route("user.profile")).
Тогда выложите сюда этот .htaccess , чтобы помочь тем, кто в будущем будет искать решение подобной проблемы.
Спасибо, симпатичное расширение, особенно приятно, что оно сразу хорошо документировано.
Но мне лично например психологически комфортнее потратить полчаса и руками прописать роуты с методами контроллеров, которые вызывают репозитории с нужными скоупами. Хотя в некоторых случая, типа админки с массой объектов с разнообразной фильтрацией, твой подход вполне может быть оправдан.
А зачем вообще понадобилось переопределять primary key , да и еще так странно ?
С чего тогда этот ларавель на руках носят? Я же пока вижу не упрощение жизни, а совсем наоборот.
А где может быть упрощение жизни ? Генерация миграций по модели ? Так в этом случае все равно придется писать руками описания столбцов, не в миграции так в модели, плюс пропадет версионность - с помощью миграций можно править структуру БД в процессе разработки приложения, а с помощью изменений в модели - нет.
Миграции вообще вещь необязательная, если приложение пишете только вы, то вы смело можете без них обойтись, просто рисуя таблицы в phpmyadmin. Миграции нужны для того, чтобы можно было фиксировать изменения БД в системе контроля версий (например, git), особенно когда работаешь в команде.
PS если нужно генерировать миграцию по существующей таблице, то для этого есть вот такой инструмент: https://github.com/Xethron/migrations-generator
Обычно действуют наоборот - у себя на компе разворачивают девелопер-окружение, на самом компе или в виртуальной машине (для laravel есть неплохое решение в виде vagrant-системы - http://laravel.com/docs/homestead ), а изменения кидают на удаленную машину, руками, скриптом, или через git-репозиторий, пуша в него (на тейлоровском http://forge.laravel.com этот способ деплоя предлагается как основной). В вашем же случае надо искать прогу, которая мапит папку на удаленом сервере на локальную машину, что-то типа http://www.expandrive.com/ или аналогов, но они работают не очень устойчиво.
Миграции надо писать руками. Из коробки в laravel не предусмотрено ничего, что бы эту вещь автоматизировано. в up() и down() пишешь команды создания и удаления изменений в БД при помощи http://laravel.com/docs/schema . Как именно выглядит файл миграции можно посмотреть на гитхабе у какого-нить ларавеловского проекта.
Генерация миграций из моделей невозможна, так как в моделях мы не перечисляем аттрибуты.
$timestamps в модели ты пишешь не для себя, а для фреймворка - чтобы он понимал, что в created_at и updated_at можно что-то писать при создании / сохранении модели. Иначе, даже если эти столбцы в бд будут, фреймворк туда писать ничего не будет.
да, значение имени столбцов в таблице я конечно же проверил в первую очередь.
с профайлером буду работать. Какой лучше не посоветуете?
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)