bjorn-mozyakin, Приветствую! Поделитесь опытом к чему в итоге пришли? На мой неопытный взгляд, передавать зависимости в модуль через конструктор (или сеттеры...) это правильное решение. Эта техника вроде так и называется - внедрение зависимостей.
Easyadmin только для очень простых сайтов, совсем простых... а может и вовсе только для обучения самой Symfony. Sonata не пробовал, но думаю и там результат будет тот, о котором написал sl0
Flying, моя ситуация следующая. На странице -/+ 10 блоков с одинаковым, подгружаемым при скролле контентом. Если подгружать каждый из них отдельным запросом, то это для каждого запроса будет инициализироваться PHP, запускаться Symfony, соединение с БД. Поэтому я решил делать 1 запрос на сервер за всеми этими html данными сразу (при первом обращении), получая их в json формате:
А возвращать html в json'е частая (допустимая?) практика или нет? Я имею ввиду, что помимо каких то статусов возвращать и html код, и все это упаковать в json в ответе.
Я понимаю, что он небезопасный и невалидный. Но нам его выдает сервис - я не могу его изменить... Да и сам сервис вроде популярный, многие его используют. Я не знаю что делать... Саппорт сервиса видимо считает, что они все сделали правильно используя такой синтаксис разметки своих параметров.
BasiC2k а что за "специальный веб-ресурс", не подскажете? Обычная почта и не вскрывать конверт не подходит, т.к. каждый из документов растаскивается на 20+ сайтов. Для всех не получится запастись необходимым конвертиком.
Дмитрий, честно я не понял этого) Мне кажется в симфони нет такого объекта со всеми конфигами, чтобы его инжектить как зависимость. Или есть? Что то мне подсказывает, что это не symfony way...
Как то со скрипом у меня идет понимание как работать с конфигами. Вроде простой компонент, простую функцию выполняет, но видимо из-за тесной связи с Контейнером возникают непонятки). Да и правила для проверки конфига - отдельная тема).
Есть пара вопросов нубских:
1. Как я понял с конфигами мы всегда работаем именно через контейнер. Если да, то чтобы получить доступ к какому то значению/массиву значений в конфиге - их нужно зарегистрировать в контейнере $container->setParameter('foo', $config['foo']); Я это правильно понял? Или все таки есть какой то объект Config в котором собраны и доступны все конфиги?
2. Судя по выводу дампа объекта контейнера в него сваливаются и конфиги бандлов, и то что мы пишем в секции parameters:, только без написания правил валидации конфига, регистрации конфигов с заданными алиасами и прочих действий. Фактически я ведь не делаю пока разделения кода по библиотекам/бандлам. Наверное и смысла тогда нет выделять для каждого "модуля" отдельную секцию в конфиге? Или смысл есть все таки? ("модуля" в кавычках, потому что фактически это же целостное приложение пока - все лежит в папке src/, и имеет одно пространство имен).
Спасибо за ответ! С вашей подачи реализовал несколько методов в контроллерах с заранее известными зависимостями, которые уже и передаются дальше. И в репозиториях навел чуть порядка. Спасибо, очень помогли!
Вадим, я уже прям отчаялся узнать в чем дело, почему у всех работает, а у меня нет - во всем инете используют первый вариант, сайт симфони о нем пишет в примерах. И получается, что у всех все работает! Вы просто спасли меня от самобичевания! Действительно первый вариант доступен так, как вы написали! Странно, что я нигде не видел инфу о особенностях вывода этих полей... ну а сам просто не догадался, по неопытности.
А как тогда лучше делать, внедрять или наследовать? Если наследовать, то и метод доступа не меняется, что мне кажется удобнее...
Да, видимо что-то типа этого! Просто хотелось бы увидеть более менее целостное решение (сложный пример), чтобы было несколько методов возвращающих части QueryBuilder'а, и в итоге составлялся сложный запрос.
