Не забывайте, что это перевод текста из репозитория на Гитхабе :) Вы можете отпулреквестить автору, и по-моему там уже появились эти вопросы. Я в свою очередь буду допереводить, а перевод здесь постараюсь время от времени обновлять.
Судя по стилю (отсутствию пунктуации и рассогласованности в некоторых местах), эта статья — перевод. Читать очень тяжело. Можете дать ссылку на оригинал?
У Эластика конечно достаточно неплохая дока, но у нее есть одна большая проблема: она не очень связная и в ней как правило попадаются не те примеры, которые действительно помогают в реальном использовании. А тут — хороший подробный разбор одной квери. По-моему так круто.
Окей, вы вот написали бандл, и что дальше? Было бы интересно узнать, например, какие были трудности, что и как пришлось реализовать, какие были интересные решения, а так получается, что вы просто свой бандл по сути рекламируете, даже особо не объясняя, в чем его прелесть и как им пользоваться.
Как-то можно избавиться от ограничений schema.org и реализовать свою собственную, не знаете? Когда сразу после релиза попробовал пользоваться ApiBundle, понял, что как-то не хочется тратить время на поиск схем, которые к тому же потом придется дотачивать до своих нужд в любом случае.
А еще очень хорошо и полезно бывает второстепенные задачи решать с помощью AOP. Например, то же логирование упрощается, и не приходится в каждый обработчик инъектить еще и логгер.
Как думаете, может, стоит сделать вариант команды init, который бы просил токен в интерактивном режиме? Всё-таки не очень хорошо оставлять токены в консольной истории, как мне кажется.
А за утилиту — спасибо! :)
Хмм, вообще, трейты — не лучшая идея, если честно. Это всё по большому счету статика, и с тестированием будут проблемы. А так, конечно, selling point у ребят мощный.
Слушайте, так всё же просто и решается вполне типовыми методами. Используйте DI, следите за количеством зависимостей, не инстанцируйте там, где не надо — и готово. Это не столько оптимизация, сколько банальный рефакторинг.
Разберитесь, как работает DI, и что можно передавать в аргументах в конструктор сервиса. Например, непонятно, зачем передавать имя EntityManager, когда можно передать сам сервис. А если вы будете базировать свое решение на сервисном слое, а не на наследовании контроллеров, будет вообще прекрасно.
Попробуйте разделить ответственность между компонентами. Типичный симфонийский подход — тонкий контроллер, толстый сервисный слой. Сейчас у вас очень толстый контроллер, и из-за этого вообще сложно воспринимать код.
Билдер фильтра нужно очеловечивать очень тщательно. Сейчас туда передается слишком уж много параметров — или уж тогда инкапсулируйте эту логику в конфигурационные объекты, или вообще пересмотрите этот API (а лучше и то, и то)
Так всё же просто — fork, push, pull request, а там посмотрим, как отреагируют. Вообще, по моему опыту, мейнтейнеры совершенно нормально относятся даже к небольшим правкам, так что можете смело предлагать изменения. Сейчас, конечно, очередь достаточно большая, но когда это мешало?
А за утилиту — спасибо! :)
А в минусах пишете, что нет разъема. Так есть, или нет? Я.Маркет об этом молчит.