говоря, у меня есть файл php с некоторыми дополнительными функциями. И мне нужно их подгрузить в момент выполнения одной из функций.
class Product extends Model
{
includeFile(Storage::disk('local')->get('functions/' . $model->id . '-' . $model->title . '.php'));
public function getProducts($xml, $model)
{
Тут я получаю данные
}
}
Получаю такую ошибку:
ErrorException
include(<?php function getCategory ($catId) {Тут функции... } ): failed to open stream: No error
попробуй объяснить задачу по другому: для чего ты это хочешь сделать?
https://getcomposer.org/doc/04-schema.md#files
Ох, думаю еще больше запутаю, но попробую. Есть товар и атрибуты. Например пол - женский, мужской. Я получаю от парсера данные в разных форматах. Например, в одном из парсеров Пол указан, как "женс". Для этого я создаю под каждый такой парсер свой php файл с функциями, которые будет использовать только этот парсер. В момент добавления товаров с этого парсера мне нужно вызвать этот файл, чтобы использовать заранее адаптированные под него функции. К примеру в данном случае использовать функцию если "женск", то вернуть "женский".
может тебе лучше сделать классы, которые ты будешь подключать и они будут делать работу
делаете отдельные сервисы под отдельные виды источник. и все приводите к одному DTO с которым уже дальше работает .. зачем эти инклюды ...
так и в чем проблема? ты же описал обычный обработчик. пишешь сервис, инжектишь где надо. это может быть даже фабрика, которая сама вернет нужный тебе сервис. иклюдить никакие файлы самому не надо. для этого есть autoload от композера. когда ты обращаешься на класс, например new App\Services\Parser(); то вызывается обработчик autoload(), который, если такого класса подключенного нет, то по имени заинклюдит файл и класс станет доступным. всё. другой момент, что DI так просто в модели не применишь, но и не надо. делай это в обсервере, хотя лучше отдельно обрабатывать, или на крайняк через app() получи свой класс
делай это не в момент добавления товара. т.е. не в модели на событии... я уже не помню даже как называется.. creating() а до, т.е. избавь свою модель от вызова такой логики, вдруг тебе завтра понадобится передать чистые данные, а не прогонять их через сервис, и withoutEvents не решение. в итоге у тебя будет какой-то класс, где ты парсишь свои данные откуда-то их получаешь, вызываешь другие сервисы, которые что-то делают своё, в итоге формируешь данные для сохранения и просто сейвишь их в бд через модель или фасад.
Обсуждают сегодня