реализация toArray в Response-классах

[mitalcoi]

Было бы очень удобно иметь в классах X\Xn\Response публичный метод toArray для конвертации ответа Webmoney в массив. Например, будет удобно логировать ответы Webmoney:

$request = new WebMoney\Api\X\X9\Request;
$request->setSignerWmid('YOUR WMID');
$request->setRequestedWmid('REQUESTED WMID');
$request->sign(new Signer('YOUR WMID', 'FULL PATH TO KEY FILE', 'KEY FILE PASSWORD'));
if ($request->validate()) {
    /** @var WebMoney\Api\X\X9\Response $response */
    $response = $webMoney->request($request);
    /** @var Psr\Log\LoggerInterface $logger **/
    $logger->debug("X9 response", $response->toArray());//второй аргумент - контекст, может быть массивом
    if ($response->getReturnCode() === 0) {
        echo $response->getPurseByName('Z000000000000')->getAmount();
    }
}

Я могу реализовать для всех Respponse toArray методы и сделать Pull-request, если дадите добро.

[chuprik]

Привет.

Архитектура библиотеки предусматривает подмену CurlRequester своим классом и тем самым можно логировать запросы и ответы :)

Если возникла необходимость получения массивом всех проперти, то или Reflection вам в помощь или можно воспользоваться менее болезненным get_object_vars.

@baibaratsky что ты думаешь?

[mitalcoi]

get_object_vars и (array) не очень помогут. первый метод выведет данные в нечитаемом формате, а второй вообще не выводит protected-свойства. Перекрыть CurlRequester может и можно, равно как и сделать форк и написать свою реализацию, но все-же иметь предлагаемую фичу "из-коробки", как мне кажется, было бы очень удобно.

[chuprik]

Важно понимать, что логирование запросов — отладка. Зачем перегружать код, который не будет использоваться в продакшн режиме? Для таких ситуаций можно «подменить» CurlRequester. И для отладки, я считаю, допустимо выводить и не особо читаемый массив (чаще всего необходимы определенные проперти, а не все скопом. Тот же X11 в принципе довольно толстый запрос).

Может все таки есть другая причина для появления toArray() в классах?

[mitalcoi]

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

[baibaratsky]

Я смогу заняться этим вопросом после 23 мая.

[baibaratsky]

Поясните, пожалуйста, почему вы хотите конвертировать ответы в массив. Если у вас стоит задача логировать ответы WM, я вам настоятельно рекомендую хранить их в сыром виде, потому как в общении с представителями платежной системы массивы будут не очень удобны: у вас будут спрашивать запросы/ответы. Для внутренних расследований тоже сырые данные более полезны. Не забывайте, что ответ может прийти такой, что и в массив его не сконвертируешь.

Мое предложение такое: я могу добавить методы для извлечения сырого ответа в классы Response. На мой взгляд, это действительно будет иметь смысл и не перегрузит библиотеку избыточным кодом. Что скажете?

[baibaratsky]

Кстати, у себя в проектах я использую подмену CurlRequester для логирования всех запросов и ответов платежных систем. Можно реализовать еще такую опцию.

[mitalcoi]

я думаю что вы правы. Действительно, иметь сырые данные более полезно.

[baibaratsky]

Добавил метод getRawData() в классы Response. Если нужны будут полные запросы и ответы (с заголовками), можно будет добавить соответсвующую логику в CurlRequester.

[mitalcoi]

Отлично. Спасибо за улучшения!

[baibaratsky]

Пожалуйста :)