правильно придумано описывать модули в аннотациях к Entity

хз. я сейчас делаю ставку на graphql

это реально похоже на правду как должно быть

но операции это ближе к контроллерам

правильно придумано описывать модули в аннотациях к Entity

какое отношение сущности имеют к api?)

почему бы не взять какую-нибудь rethinkdb

Ну как какое- там же свойства моделей АПИ описываются в аннотациях к Entity

и сами операции там же

и это косяк

потому что могут быть операции в которых на входе 3 разные сущности - на выходе 2 другие

а там все коряво под CRUD заточили и все

блокировать до задачи и снимать лок в конце + retry если залочено

у тебя все равно выйдет синхронное эксклюзивное выполнение равнозначное очереди

хотя волшебно читает связи из ОРМ

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

операции нельзя по своим тегам сгруппировать - элементарнейшая фунция в сваггере

ну в общем - мое ИМХО - в api-platform есть хорошие задумки - но архитектурно они криво все сделали...

если взять их некоторые начинания с автогенерацией доки и автогенерации моделей по ORM и просто кропотливо реализовать все возможности Swagger - получится конфетка

если взять их некоторые начинания с автогенерацией доки и автогенерации моделей по ORM и просто кропотливо реализовать все возможности Swagger - получится конфетка

меня больше прельщает кодогенерация по доке нежели генерация доки по коду

Я так делал раньше

если уж генерация доки по коду - то штуки типа graphql которые декларируют вообще всю схему апишки

что бы можно было использовать сгенерированную документацию для верификации

Писал сначала json - потом когда нашел плагин в phpstorm для сваггера - начал писать yaml

Наоборот генерил код silex для маршрутизации - есть свой небольшой класс который это делает

и свой CRUD был написан для обработки типовых операций

Но в итоге много сделав именно по пути генерации кода по доке - как-то вот путь api-platform мне сейчас больше нравится

просто это эффективнее - описываешь поля БД - а заодно сразу и сущности АПИ фактически...

экономишь время на разработку

хотя еще подумаю, я уверенно решил начать писать на сф. А вот как сделать свое первое АПИ на сф - пока не понял. Сроки по проекту уже поджимают. Возможно придется взять ОРМ от сф и свои наработки по АПИ просто.

меня больше прельщает кодогенерация по доке нежели генерация доки по коду

плюс этого решения - yaml может писать не программист - а например аналитик, если более-менее сообразительный...

А что с fos rest то не так? Дока на инглише?

А что с fos rest то не так? Дока на инглише?

Ну как тебе сказать, почти все

Ну как тебе сказать, почти все

А по подробнее? Использовал в трёх проектах, полет нормальный

Ну на инглише я с французами вроде общий язык находил - но че-то не зашло вообще сегодня - правда спал 3 часа...

Начал читать - походу мне просто знаний по сф не хватает

я нихрена не понял на сттранице про сериализацию - при чем тут формы вообще...

на том решил на завтра уже это отложить

А что с fos rest то не так? Дока на инглише?

то же что и с fos user bundle

примитивная штука

которая на чуть более сложных кейсах создает больше проблем чем решает

http://symfony.com/doc/master/bundles/FOSRestBundle/2-the-view-layer.html - вот на это час сидел смотрел... И у меня лопался мозг, как сериализация может быть связана с тем же twig... Возможно мне просто не хватает щас какой-то доки для чайников... Где бы неско простых примеров было бы описано "сквозных" (то есть написать мелкое прилоежние от начала до конца и чтобы оно работало)

А по подробнее? Использовал в трёх проектах, полет нормальный

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

Блин вот с рест приятнее в ларе работать. :)

Но это не точно. :D

Ребята, глупый вопрос... никак не удается получить доступ к сервис-контейнеру в Symfony 3... чистая установка... нечто типа такого use Symfony\Bundle\FrameworkBundle\Controller\Controller; class DefaultController extends Controller { protected $serializer; public function __construct() { $this->serializer = $this->get("jms_serializer"); } }

в убой не вижу в какую сторону копать :)

в сервисе вроде пробовал добавлять calls: - [ setContainer,[ '@service_container' ] ]

А ты не перекрыл родительский конструктор? Либо с lifecycle проблема и в конструкторе он еще не доступен. Короче проверь.

да вроде и нет у него родительского контсруктора

Ну значит перенеси в экшн.

Но это не точно. :D

Главное не проверять)

да вроде и нет у него родительского контсруктора

Зачем тебе вообще $this тут? ->get() возвращает один инстанс.

может ты и прав... секунду

точно... так работает... )

так и думал что где-то я перезаморочился...

пасибки... Это я домашнюю работу от fes0r'а делаю )

☺️

даже кажись получается с этим DDD )

@Gaaarfild а ты чего в Скайпе игнорируешь? )))

@Gaaarfild а ты чего в Скайпе игнорируешь? )))

Разве? Я ж вроде отвечал.

Блин вот с рест приятнее в ларе работать. :)

rest апишек не бывает.

rest апишек не бывает.

Ну мы уж не про идеальный рест.

А про то что все привыкли называть им. :)

Ну мы уж не про идеальный рест.

идеальный rest это web

А про то что все привыкли называть им. :)

http api короч

Ребята, глупый вопрос... никак не удается получить доступ к сервис-контейнеру в Symfony 3... чистая установка... нечто типа такого use Symfony\Bundle\FrameworkBundle\Controller\Controller; class DefaultController extends Controller { protected $serializer; public function __construct() { $this->serializer = $this->get("jms_serializer"); } }

не используй jms serializer

никогда

ERROR: S client not available

сожги его

убей

(хотя может его за 2 года уже переписали но я сомневаюсь)

О а почему кстати? Я других и не знаю.

symfony/serializer

лучше потому что разделяет процесс сериализации и нормализации/денормализации

и намного проще свои хэндлеры делать

а jms serializer - вот у тебя все хорошо было и вот ты уже пишешь свой визитор/ивент листенер

А как там визибилити и всякие другие вещи делать?

Типа глубины сериализации и виртуальные аксессоры.

Sergey дай мне тоже это домашнее задание

если что-то сложное - просто пишешь свой хэндлер

явно

да это скучно но зато предсказуемо

и если посадят на проект нового человека не надо будет объяснять ничего долго.

В общем, воркфлоу чуток отличается, да?

чуточку

Я вот тоже за дефолтный сериалайзер, но наши уперлись были в jms типа там дофига функционала

А у меня знаний не хватает чтобы доказать обратное))

Я вот тоже за дефолтный сериалайзер, но наши уперлись были в jms типа там дофига функционала

они просто еще не испытали боли с ним

Видимо задач ещё таких не было

ну у меня доводы простые: - что бы нормально им пользоваться его надо знать. А знают его не многие. - Экономия времени которую дает jms serializer выражается минутами. А проблемы обходятся часами. - в последний раз когда я его юзал jms любил пустые коллекции сериализовывать как {}

я хоть и ленивый но я лучше ручками объект соберу и разберу

у меня на это уйдет минут на 10 больше на сущность но зато я полностью контролируют ситуацию

А пример такой разборки сборки не можешь где-то скинуть?

юзаю fos rest + jsm serializer

+ nelmio для доки

не без проблем, конечно, но ничего глобально проблемного

А пример такой разборки сборки не можешь где-то скинуть?

лень

не без проблем, конечно, но ничего глобально проблемного

а какого рода апишки?

просто если там тупо CRUD то да)

товары, поиск, проекты, добавление проектов, фоток, регистрация, аутентификация