Обработка POST запросов AngularJs в Symfony2

[kriptomen]

На то он и микрофреймворк. В Symfony другой уровень абстракции получается.

[Fesor]

Ну вообще можно сделать middleware для любых HttpKernel-based приложений и использовать что в Silex что в Symfony что в Laravel. Что до Silex, это конечно здорово, но только для небольших проектов подходит. Чем больше проект — тем больше бойлерплейт кода приходится использовать. Лично я отказался от идеи использовать маленький милый silex для REST и вернулся к Symfony.

[limitium]

В своем проекте написал транслятор симфонивской формы в json, в котором указываются типы полей и прочая муть + конечно же значения. А в ангуляре написал сервис, который этот json понимает и достает оттуда данные и конвертит обратно в application/x-www-form-urlencoded при сабмите. В итоге смог использовать старые описания форм + валидацию.
По хорошему надо, что-то подобное, но сильно лайтовее. По модельке строить json с типами дынных + валидация.

[kriptomen]

В открытом доступе (на гитхаб, там) этого нет, посмотреть?

[limitium]

Решение это временное и написано не очень. Но, если инетерсно, дома буду — оформлю в каком-нибудь виде.

[Fesor]

и конвертит обратно в application/x-www-form-urlencoded при сабмите

Простите, но зачем? Это как бы считается плохой практикой. Не просто так как бы Angular не занимается такой чушью а шлет старый добрый JSON.

Вообще для REST можно просто выкинуть symfony/form и оставить только jms serializer + symfony/validator. Выходит намного удобнее с десериализацией запросов в объекты, сразу же их можно валидировать и возвращать ошибки со статус кодом 400. В этом случае можно дописать обработчик ошибок для angularjs который будет все это добро обрабатывать корректно и реюзать из проекта в проект.

[limitium]

Да практика плохая, но вот, то что я пытался использовать из досутпных бандлов не позволяло плавно переходить от стандарта form+twig к angular и rest. При этом ничего не переписывая.

[Fesor]

Ну вот вы бы этот момент уточнили сразу. Хороший вариант перехода.

[Fesor]

Подобная штука есть в FOS rest bundle.

Вообще с JSON запросами можно делать много вкусного, можно например десериализовать объекты напрямую в сущности (или в DTO) и передавать их с запросом, при этом существенно уменьшая объемы скучного и тупого кода. Словом много чего можно придумать забавного вооруживщись еще и JMS Serializer.

[2fast4rabbit]

Для того что бы не городить костыли в PHP проектах (не важно на каком фреймворке) достаточно указать content-type по умолчанию для всех post/put запросов отправляемых через $http:

var app = angular.module('my_nifty_app', [...]).config(function($httpProvider) {
    $httpProvider.defaults.headers.put['Content-Type'] = 'application/x-www-form-urlencoded';
    $httpProvider.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded';
});

[Fesor]

маленькое НО, посылаете вы всеравно application/json, angular вроде как не умеет json в postdata конвертить, и к этим двум строчкам приходится еще и трансформер для запросов писать. И тут есть нюансы, так как в PHP том же например массивы немного по другому отрабатывают нежели в том же .NET. JSON в этом плане универсальнее, проще, да и не вижу никаких проблем с этим.

[2fast4rabbit]

Используете jQuery.param(). Если не используете jQuery, то посмотрите как реализованна функция param() и скопируйте ее.

[Fesor]

Да я знаю как это реализовывать, на этот случай у меня есть готовый трансформер который нужно только подключить. Мне лично как backend разработчика application/json полностью устраивает. Так же как это устраивает с точки зрения frontend. Если API не мое, то понятно, но лично мне удобнее на уровне обработки запроса сразу трансформировать json в сущности и работать уже с ними, еще больше упрощая код контроллеров и делая их максимально тонкими. Так как статья о Symfony и серверной части, то значит API наше и мы можем работать с JSON, так зачем тогда нам x-www-form-urlencoded?

Плюс angularjs в том что он предоставляет нам прозрачный сервис, который при помощи трансорматоров приводит запросы к нужному нам виду, и мы не заботимся об этом в коде нашего приложения. Плюс Symfony — абстракция над HTTP так же позволяющая нам изменять запросы по необходимости, что бы код приложения становился проще.