HTML + CSS имеет смысл лишь при разработке под несколько платформ. При разработке под только одну - это крайний случай, лишь когда стек разработки требует, т.к. огрести багов можно тонны. Ну либо это очень простое приложение.
Александр Евгеньевич: Ну это не тру вей. Конечно свои костыли приятнее, но команда более одного\двух человек. Если бы я работал в одиночку, то вообще брал бы стек Laravel + SleepingOwl + Dingo (ну или натив, благо в ларке это запросто делается).
Radik_Wind: а почему тогда это называется DI, а не Parameters Injection? ;)
Так вот, если говорите что всё же есть инъекции в методы, то как это вызвать так же, как в phpdi, laravel, джавовских реализациях и проч.? Метод в моем случае должен соответствовать поведению метода контроллера, т.к. это и есть почти что контроллер, но взаимодействующий с другим источником данных, нежели хттп запрос.
Radik_Wind: почему это не имеет отношения к DI? DI == Dependency Injecton, т.е. автоматичекая подстановка (инъекция) зависимостей, оно делится на три типа - инъекции в конструктор, инъекции в поля и инъекции в методы. В Symfony присутсвует два из них, насколько я понял - это в конструктор и в поля (сквозь вызов метода set). И в костыльном виде инъекции в методы контроллера. При этом в современной практике инъекции в поля являются антипаттерном, в тоже время инъекции в конструктор и в методы - общепринятые "нормальные" подходы.
Radik_Wind: Почему это? Метод N требует интерфейс A и B - классический принип инверсии контроля, осталось их как-либо автоматом посылать туда. Хорошо бы чтобы этим занимался сам DI контейнер, т.к. это его задача предоставлять зависимости, но в реализации симфони он этого тупо не умеет и является скорее сервис локатором, а не DI.
voronkovich: В случае же вызова этого метода A с какими-либо аргументами - вы сами вольны передавать ему какие угодно аргументы, проблема лишь в том, чтобы
1) определить что это за аргументы
2) есть ли они в контейнере
3) подставить их из контейнера (если есть)
voronkovich: вы меня ну вообще не поняли. Метод, допустим A вызывается 10 раз и вы хотите сказать, то при каждом вызове метода A декларированный в нём $this->someDependency будет каждый раз новым? Нет, нифига - он будет тем же самым, что установили один раз в конструкторе этого объекта или через сеттер.
Вполне годный вариант. НО! Оно срабатывает один раз, с тем же успехом можно инжектить в конструктор и не париться.
Но проблема в том, что требуется, чтобы при каждом вызове метода - прилетал новый инстанс зависимоси. Пример с контроллером:
use Symfony\Component\HttpFoundation\Request;
class SomeController
{
public function index(Request $request)
{
// При каждом вызове метода index - возвращается новый реквест, в зависимости от, собственно, реквеста
}
}
27cm: ну зато работает. SomeUser полностью повторяет поведение User при этом его можно полностью кастомизировать. Т.е. именно то поведение, что и требовалось.
chelkaz: блин, комменты скрыты - хрен разберёшься, даже не увидел, что оно есть. Тогда снимаю свой вопрос - значит бага происходит до инициализации ядра.
Тарас Сереванн: но на всякий случай повторюсь - наша беседа в комментариях не сильно относится к поставленному вопросу. Это лишь совет как ещё можно упростить\улучшить взаимодействие объектов, сделав их чище и меньше завязанными на реализацию самой БД.
P.S.
new WallPost конечно нужно будет писать, но только тогда, когда нам нужно будет создать новый объект, а не получить уже существующий в БД.
Эта плюшка позволит восстановить объект в том же самом состоянии, в каком его сохранили не вызывая конструктор, при этом через ту же самую рефлексию можно проставить нужные значения для полей.
Т.е. мы получаем в руки инструмент, который позволит писать исключительно логику взаимодействия объектов (пост + юзер), не сильно заморачиваясь по поводу как именно они взаимодействуют. Этим должен заморачиваться тот, кто взаимодействует с самой базой данных.
Я думаю этого вам хватит: https://gist.github.com/SerafimArts/de9900f9977780... чтобы заречься в ближайшие 5ок лет использовать html\css в разработке под мобилки.