Conekta Php library release(3 .3 . 0)

Con motivo de tener mejores estándares de código, convenciones de variables y un flujo mas entendible para los desarrolladores se planeo refactorizar algunos componentes dentro de la librería Conekta-php.

Summary

• CamelCase Standard
• MultiHandler Exception Implementation
• Exception restructuration
• PHPUnit Test Implementation
• PaymentSource Fix #1
• PaymentSource Fix #2

Explanation

El primer cambio realizado se planteo tener una mejor convención de código adoptando CamelCase tanto en funciones como en variables de esta forma implementar mejores practicas en la librería y también en caso de que alguien quiera contribuir con la librería de php se podrá aprobar de una forma mas rápida los pull request’s que sigan este estándar de código

Dentro de los cambios que mas resaltan en este release se encuentra el manejo de Excepciones la cual anteriormente se manejaba de la siguiente forma:

Un objeto ErrorList que contiene una “lista” de excepciones y esta lista se itera para poder acceder a ella como un objeto del tipo Exception.

$errorDetail->getMessage();

Tratando todas las posibles excepciones como un Arreglo de instancias de error donde se identificaban dependiendo del tipo de respuesta que respondía el api.

Esto cambio ya que ahora el objeto que pasa a travez de su instancia no necesita ser un objeto hijo, ahora se encapsula el objeto a nombre de su tipo de error.

Antes:

Básicamente el flujo de disparo de excepciones para la version 3.2.0 dictaba que cuando la petición retornada de la api, se comprobaba que estatus de la cabecera para saber que tipo de respuesta había regresado la petición , si esta era una respuesta diferente a 200 (Exitoso) procedía a realizar la comprobación de la api si era API 1.0.0 ó API 2.0.0.

Después:

Con este flujo se elimino una recursion que hacia la clase ErrorList ya que para la version 2.0.0 de la api se regresa un arreglo de multiples errores y esta clase tenia como misión iterar esta respuesta y pasarla a la clase Error para empaquetar cada error con su tipo de clase, teniendo al ultimo un arreglo de errores lo que hacia difícil identificar y dividir las excepciones.

De esta forma la clase Handler abstrae a ErrorList empaquetando los errores como un solo objeto de una sola clase.

teniendo primeramente un solo metodo:

que identifica como esta compuesta la respuesta resultando con un manejo de errores de la siguiente forma:

Implementando multihandling exception haciendo mas fácil el “debuggear” el código para los desarrolladores.

El funcionamiento de esta reestructuración te permite tener las propiedades de un objeto tipo Exception con los métodos que lo definen:

$e->getMethod(); 
$e->getCode();
$e->getLine();
$e->getTrace();
$e->getTraceAsString();

Los cuales te regresaran la ultima linea de error en caso de la API 2.0.0 y en caso de ser API 1.0.0 regresara el único error esperado ya que esta version solo regresa un solo error por petición.

Para tener la misma propiedad de la API 2 y tener el stack completo de excepciones se implemento un método llamado

$e->getConektaMessage();

El cual te permite obtener todo el objeto de error con la misma clase de instancia, es decir tener un ParameterValidationError con todos los parámetros que están incorrectos en tu petición.

Las pruebas unitarias anteriormente se manejaban por medio de la librería SimpleTest la cual se remplazo por PHPUnit test que nos brinda un mejor manejo de errores sobre la ejecución de los test unitarios ya que nos provee del tiempo de ejecución, memoria y indicador en porcentaje de los test que fueron asentados sobre el total a diferencia de SimpleTest que solo nos daba información sobre el stack trace (linea de errores) sobre la que había fallado el test y el nombre del test.

Nota: puedes leer la documentación con los pasos para correr los test’s en el repositorio de conekta-php

Por ultimo se implemento una solución para PaymentSources ya que esta tenia un problema de instanciación de clase. Esto se daba al borrar un payment source del objeto Customer.

//find customer
$customer = Customer::find($id);
//delete source with id => 0
$customer->payment_sources[0]->delete();
//create new payment_source attached to a customer
$customer->createPaymentSource($paymentParams);

Gracias a Jaime que nos notifico que este flujo tenia errores fue que se pudo corregir ya que al borrar un payment_source en la función delete se hacia un:

unset($this->$parent->$member);

borrando el objeto que hacia referencia a la clase PaymentSource es por eso que en la siguiente linea ya no se tenia la referencia a la clase y retornaba un error que no se tenia contemplado en base a que no se tenia instancia de payment_source, solucionado ese error se puede hacer sin problema alguno este flujo.

El segundo Fix es referente a poder borrar multiples payment source’s el cual nos reporto Daniel (Gracias también a ti!). El problema recaía cuando se intentaba hacer un ciclo de borrado para el objeto payment source de un Customer:

//It works
$customer->payment_sources[0]->delete(); 
//Does not works
$customer->payment_sources[1]->delete();

Este error se replico con la version 3.2.0 de la librería de php pero se soluciono ya en la version 3.3.0 con el fix anterior.