Где лучше всего формировать URL для файлов на laravel перед отправкой на клиент?

Question

[lexstile]

В БД у проектов есть поле - логотип - название файла и расширение (например, 232323.jpg)
Вопрос в том, на каком этапе и где мне перехватить данные, чтобы можно было сформировать абсолютный путь для изображений? (например, site.ru/storage/232323.jpg)

\app\Http\Controllers\ProjectController.php

public function get()
    {
        return Project::projets(request()->user()->id);
    }

\app\Models\Project.php

static function projets($id)
    {
        $limit = request()->limit ?: 10;
        return Project::query()->where('user_id', $id)->simplePaginate($limit) ?: [];
    }

Comments

[Арамаис Мирзоян]

Передайте название логотипа во view и там генерируйте путь

Например так

<img src="/storage/{{$post->logo}}">

Или используйте функцию url() во view, чтобы получить абсолютный путь. Как решение подойдет сохранить в базе путь а не название, например, /storage/232323.jpg, и во view вывести через url().

[lexstile]

Арамаис Мирзоян, благодарю за ответ, а если пусть изменится, проходится по всей базе и менять пути?

[Арамаис Мирзоян]

lexstile, да, придется, но это не совсем удобно.

Answer 1

[Дмитрий]

Defing accessor

class Project extends Model{
............

public function getFullUrlAttribute(){
           return функция которая делает из атрибута полной путь();
}
.........
}

во вью {{$project->full_url}}

Comments

[Андрей Мелентьев]

А ещё лучше пользовать готовые решения , аля spatie/medialibrary (надеюсь верно написал), и вообще забыть про такие проблемы.

[Дмитрий]

Андрей Мелентьев, тянуть библиотеку ради чего? одного файла с логотипом? имхо это избыточно

[Андрей Мелентьев]

Дмитрий, а он точно один? И вы точно понимаете что в дальнейшем у вас не будет ни каких файлов или изображений? Вот прямо 100%. Если нет то я бы просто поставил, есть пить не просит от головной боли избавляет.

[Дмитрий]

Андрей Мелентьев, я точно сколько у меня чего будет, но вопрос задавал не я. И что там твориться в проекте мне неизвестно, по этому я предпочитаю смотреть на вопрос - там один логотип, к которому надо добавлять путь. А подход: вижу картинку - надо ставить комбайн для работы с картинками - предлагаю считать избыточным.

[lexstile]

А если это API, а не вью, как мне отправить на FE уже ссылку подобным образом?
Я описал в модели:

public function setLogoAttribute($logo)
    {
        return 'https://site.ru/storage/' . $logo;
    }

[Дмитрий]

lexstile, в ларки для апи стоит использовать resources к которые позволят вам использовать $model->logo. Но если лень - поглядите в свойство моделей $appends оно ровно и было предназначено для того что бы пришлепывать к атрибутам моделей всякую фигню при сериализации

class Project extends Model{

protected $appends = ['full_logo'];

public function getFullLogoAttribute()
    {
        return 'https://site.ru/storage/' . $this->logo;
    }
}

Только - использовать здесь setter не верно. Что вы будете делать когда домен поменяется? Базу перелопачивать?

[lexstile]

Дмитрий, ой, я не заметил, что сеттер прислал, спасибо!
хотел геттер. Полчаса назад писал в комментарии об этой же проблеме, если хранить в БД абсолютные УРЛ.
А правильно ли я понял, что в случае с appends нельзя менять существующие поля, только создавать новые? (например, я не могу logo заменить на модифицированный logo?)

[Дмитрий]

lexstile, в случае с appends не имеет смысла менять существующие поля - они и так при сериализации у вас там окажутся. По этому добавить вы их в $appends можете но толку будет ноль. А если вы пропишете getter для существующего поля - он будет при сериализации использовать его. Собственно если зайти в trait HasAttributes в ларке вся эта магия будет видна.

[jazzus]

Дмитрий, ресурсы не просто так придумали. Связи, набор полей для разных запросов к одной модели и т.д. Вдруг у него там в проектах конфиденциальные поля и он их тупо на фронт вывалит, как часто в Ларавел проектах бывает. Лучше сразу делать по нормальному.

[Дмитрий]

jazzus, ресурсы придумали относительно недавно, а до этого с тем что бы не вываливать конфидециальные поля тоже боролись и для этой борьбы придумали свойство $hidden.

[jazzus]

Дмитрий, а потом если тебе нужны эти конфиденциальные поля в админке ты продолжишь костылить. С ресурсами гораздо больше контроля и удобства

[Дмитрий]

jazzus, открою страшную тайну сериализация нужна не только что бы с апи работать. По этому использование Resource вас от использования appends и hidden не спасает.

[jazzus]

Дмитрий, кого где что не спасает нужно разбирать на конкретном примере. В данном примере (json ресурсы) нужно использовать Ларавел ресурсы ибо захочет притянуть к проектам user.profile и вывалит и в них все, что не надо. Не надо приучаться к костылям, когда ты используешь фреймворк и есть удобные инструменты.

[Дмитрий]

jazzus,
1. не надо. не надо разбирать. если у нас есть конфедициальные поля - пихаем в hidden. и даже если у вас все в ресурсах и ресурсами погоняет.
2. Без ресурсов сделано вагон проектов и ничего живут, при помощи appends и hidden. И вроде как подают признаки жизни. То что ноне стоит использовать ресурсы я указал сразу же. Но и использование hidden appends крамолой или костылем не является - по моему глубоком убеждению.
3. Если у вас есть желание продолжить бомбить от того что кто то написал - если лень юзать ресурсы юзайте это, то может вы найдете другого человека?

[jazzus]

Дмитрий, конфиденциальные поля в одном месте конфиденциальные, а в другом нет и придется продолжать костыль. К тому же нет смысла отдавать на фронт лишние данные, даже если поля не конфиденциальные. Проекты есть и с 4000 дублирующих запросов на одной странице и возможностью зарегить админа кому угодно. И ничего, живут. Автор новичок, который может не знать, что делает и лучше ему учиться сразу делать красиво и безопасно.

[Дмитрий]

jazzus,
1. И по этому стоит выучить основное правило - сначала ВСЕ ЗАПРЕЩАЕМ, потом в нужных местах разрешаем. Это азы запиливания доступов. По этому не стесняемся - запихиваем в hidden
2. И этому автору как правильно делать я указал. С ссылкой. Но если проект маленький и ресурсы там избыточны я указал и второй вариант. Автор вопроса теперь знает два варианта. И сможет выбирать

[jazzus]

Дмитрий, азы доступов, как раз наоборот - должно быть запрещено всё, что не разрешено, а не запрещено только то, что ты прописал. Для этого нужно прописать то, что разрешено. Это логично, просто контролировать и так работают, например, политики в Ларавел. Пишешь $model->user_id === $user->id и все остальное мимо. С ресурсами также - добавил 3 нужных поля и потом пофиг какие ты со временем поля в модель добавил, забыл/не забыл и т.д. на фронт улетит только то, что тебе нужно.

[Дмитрий]

jazzus, и еще раз. настраивая доступы сначала все запрещается, потом пишется а что и кому можно и это базис. И здесь ровно тоже самое - если есть чувствительная информация - сначала запрещаете доступ в моделях hidden потом если нужно пишете свой вариант сериализации для конкретного DTO или чего у вас там.

[jazzus]

Дмитрий, когда ты прописываешь в hidden твой базис нарушается. Ибо далеко не ВСЁ запрещено, а только то малое, что ты прописал. Сам себе противоречишь.

[Дмитрий]

jazzus,
1. я себе не противоречу. я вношу критичные поля в список скрытых. после чего могут быть спокойным что она нигде не вывалится. а там где мне надо что бы вывалилась - руками прописываю - вываливайся. Ровно как надо. Не я конечно понимаю resource всему голова - но к сожалению не всему.
2. Мы с вами на ты не переходили
3. Разговор меня начинает утомлять. Так что вы Д'Артатьян весь в белом. Я вообще в ларке не секу - можете распечатать и повесить себе на стену и расслабиться

[jazzus]

Дмитрий, Ларка ладно, главное в азах доступа разобрался.

Answer 2

[jazzus]

В геттере, как уже написали, который вызывать в Ларавел ресурсе, который отдавать из метода контроллера с названием index. Еще можно убрать из модели лишние методы, чтобы не было каши типа Project::projets и модель не превратилась в простыню.

Comments

[lexstile]

Спасибо большое за ответ.

В геттере, как уже написали, который вызывать в Ларавел ресурсе, который отдавать из метода контроллера с названием index.

Вы имеете ввиду создание геттера в модели, как предложил Дмитрий?
Или вы имели ввиду про другое решение?

Еще можно убрать из модели лишние методы, чтобы не было каши типа Project::projets и модель не превратилась в простыню.

Убрать? или переименовать?
Просто нужен же список проектов.

[jazzus]

lexstile, как Дмитрий + вызывать геттер в АПИ ресурсе, а ресурс в контроллере. Метод из модели убрать в контроллер если не повторяется или вынести в свой класс если повторяется. Подобных методов в модели быть не должно. Ну и называть методы контроллера правильно (см примеры в ресурсном контроллере), а лучше сразу генерить ресурсные роуты/контроллеры с помощью Ларавел ибо get по смыслу это и index может быть и show в апи контроллере.