Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Если у Вас в отдельной папке всё лежит в app, насколько я понимаю, то подключите её через psr-0/4 в composer.json:
"autoload": {
...
"psr-4": {
"Example\\": "app/Example"
},
...
},
...Дальше, правильно установив namespace в файлах, Вы позволите компоузеру заавтолоадить всё, что в Example и провайдер найдётся...
А что у Вас в компоузере прописано для автозагрузки всего этого?
Поробуйте начать с азов, а там станет понятно: https://laracasts.com/lessons/namespacing-primer
Ну, каг бэ
Auth::login($user);Что то я совсем запутался, а как бы это выглядело? а если в items_options_value не будет записей?
Прошу пардон - упустил, что obj имеет item.
В таком случае, вопрос поставлен некорректно. Отношение Obj и Item - N:1. То есть, у Obj только один Item. "Из модели obj выбрать items со всеми items_options_value принадлежащих items" не получится, так как на один obj - один item.
Если же Вы хотите получить все options для набора Item, который связан с Obj, тогда Вам опять-таки, как я писал, можно пойти от таблицы items_options_value. А именно, Вы получаете нужные Obj по требуемым условиям (в результате у Вас будут item_id). Далее, делаете выборку из items_options_value по имеющимся ключам item_id.
В целом, можно обойтись и одним запросом, вставив первый запрос в условие на выборку по item_id второго запроса. В итоге, у Вас будет один запрос и возможность получить все связанные свойства нужных объектов...
Практическую реализацию данного подхода, думаю, сможете почерпнуть из примеров, мануалов, либо подсказок ниже?
Упростите себе задачу - сделайте выборку из таблицы items_options_value. Тогда все отношения будут belongsTo (меньше запросов), а условия запроса будут реализовываться проще...
Именуйте классы моделей с учётом psr-0, либо используйте namespaces, перенеся модели в другую папку, которая в группе автозагрузчика компоузера будет обозначена разделом psr-4:
"autoload": {
"classmap": [
"app/commands",
"app/controllers",
"app/models",
"app/database/migrations",
"app/database/seeds",
"app/tests/TestCase.php"
],
"psr-4": {
"Acme\\": "app/Acme",
}
},А по старинке залить собранный проект на хостинг по ftp без всяких там гитов и компоузеров? На локале разворачивайте, настраивайте ресурс, а потом как в лихих девяностых: нортон коммандер и копируем на хост... ![]()
http://laravel.com/docs/eloquent#eager-loading
В модели Треков прописывайте отношения к Альбомам и Брендам (belongsTo), а в запросе на Треки используйте with() на нужные свойства. Полученные объекты Треков будут иметь данные по обоим этим признакам ($track->brand, $track->album)...
И опять, ман Вам в помощь.
А где сам запрос? Что смотреть-поправлять-подсказывать?
По нескольким данным нужно делать запрос с несколькими where(). Ман в помощь для начала...
Всегда пожалуйста!
По поводу библиотеки для nested sets - по описанию хороша. Даже с поддержкой soft delete. Для инет магазина, если будет интеграция с учётными системами, полезно...
Command Bus в данном случае элегантно решит проблему. Но да, нужно заморочиться с первоначальной реализацией (если же нужно делать под себя. Если же нет - то Commander в изначальной реализации Jeffrey будет весьма достаточно), однако при развитии проекта множество вещей станут проще в реализации и поддержке, а использование имеющегося кода и тестирование станет легким и непринуждённым занятием...
Я бы сделал справочник категорий, типов, свойств (зависящих от категорий и типов). Категория и тип - это по-хорошему признак товара (n:1, товар принадлежит категории и типу - или даже просто типу, а категория - это признак типа), а и уже кроссами (n:m) связывал конкретный товар с соответствующими свойствами.
В такой структуре категории и даже типы можно реализовывать в виде деревьев (реализовывать вложённости сколь угодно сложные), все товары того или иного типа будут обладать определённым, настраиваемым набором свойств (обинаковым для одного типа, но при этом, отличающимся от другого типа), можно будет производить поиск по любому из свойств типа, формирвоать динамические фильтры по свойствам в зависимости от типа товара, сравнения и прочее...
Слабым же местом в этой истории является, по-моему, Eloquent. В текущей его реализации определённые запросы будут не до конца оптимальными (можно попасться на хорошие тормоза, если ограничение выдачи будет настраиваемой и в максимальном выражении очень большой). Нужно будет писать не ORM запросы. Но это не очень страшно, так как будет работать только на списках с фильтрацией. Плюс - грамотное кэширование спасёт отца русской демократии.