Jedi, да не делается это в мидлварях. Хоть dry хоть не dry. представим понадобится на фронте/классах проверить. Тогда конкретный DRY будет. Придется выпиливать из мидлварей в свой сервис классы. А потом узнаешь про политики авторизаии и захочется зарефакторить т.к. доступ со всего ларавел и кода почти нет - а это сносить все мидлвари с сервис классами и всю сопутствующую инфраструктуру. Целый раздел Ларавел посветили политикам, думали старались. Нужно юзать)
Сюда не хочется :)
зря. Здесь бы подсказали как правильно. И не только мое мнение. Только нужно логику описать понятно без контентов. Если идею боися раскрывать можно трансоформировать в близкие аналоги, но чтобы логика сохранялась.
структура самого проекта не такая уж узкая
сложно и долго т.к. велосипеды. Можно пилить узкие решенгия в рамках ЛАравел т.е. без сырых запросов и с минимумом кода.
Jedi, это все очень плохая идея. С расширением приложения придется серьезно говонокодить, чтобы оставаться в данной структуре либо все сносить и делать заново. Рекомендую подумать над структурой пока не поздно т.к. задача скорее всего очень простая.
у меня есть Middleware, который проверяет, кто создал данный пос
с уникальным слагом в такой проверке нет необходимости. Тем более в мидлварях (там такое не делают). Если цель показать контент (что все таки это? :)) то добавляешь ->shallow() к ресурсному роуту и он сформирует ссылку вообще без поста domen/content/slug далее 1 метод show без всяких непонятных дополнительных show-методов и он сам либо найдет content либо покажет 404
Jedi, slug уникальный и он сам найдет по ключу. Про пост написал, а в контент что? Зачем пост для разного контента? Я бы делал модели Video Article Question. Ну даже если прямо все одинаковое и только тип разный, то можно сделать type_id со связью с types. Но все равно плохая идея смешивать разные сущности в одной таблице. Если только это не полиморфный случай. Но здесь не он. Сделай 3 разных модели и забудь пост с контентом как страшный сон)
но таких практик в Ларавел не видел и слава богу. Достаточно просто именовать "без длинных конструкций" убрать ненужное account и следовать примерам из доки. Либо писать user.index и внутри шаблона делать @can
Иван Шумов, стартапы лучше делать в небольшой команде единомышленников без напряга и контроля. Чтобы атмосфера была соответстсвующая. А шаблонный интернет-магазин и визитку - да можно заказать на фриленсе ну это какбы мое мнение я не настаиваю)
Sanes, тогда не понял подробнее? мне нужно по всем статьям пользователя показать таблицу посетителей, где будут отображаться связанные данные посетителей. Делать к данным запросы, фильтрацию, сортировки и т.д.