Clases con las constantes

[alphp]

Clases con las constantes para:

• setCurrency
• setTransactiontype
• setMethod
• setLanguage
• setMerchantCofType

Se trata más de una idea que de una PR en condiciones de ser añadida.

Cosas que añadir:

• [x] Añadir métodos estáticos de validación
• [ ] Cambiar los nombres por otros más adecuados (inglés?)
• [x] Añadir tests
• [ ] Actualizar la clase Tpv para que use los métodos de validación
• [ ] Añadir documentación Redsys

Comentarios y propuestas en #97

[ssheduardo]

También estaba dándole una vuelta al tema de los nombres, si en Ingles o Castellano, dado que Redsys es en Castellano, la mayoría que usa la librería es Hispanohablante.

[alphp]

Lo ideal sería que hubiera cierta coherencia en el código, pero en la misma documentación de Redsys ponen unas cosas en inglés y otras en castellano: También he añadido una carpeta con al menos la documentación de las tablas en formato MD, me gustaría poner toda la documentación posible (y enlaces a la oficial).

[ssheduardo]

Ya, toda la razón, no lo tienen normalizado, el tema de la documentación lo he visto y esta bien. De momento no tocamos Tvp.php y encima tenemos los test así que genial. Cuando veas me dices para hacer el merge de esto nuevo.

[alphp]

Estoy cerrando un proyecto, en un par de días repasaré todo y liberaré la PR. Quiero dejar "cerrado" el tema de los nombres de las constantes ya que sería lo que luego de más guerra. También quiero revisar los Enums de la v2 para que la transición entre la v1 y v2 sea trivial.

[ssheduardo]

Nada tranquilo, hay tiempo para hacerlo, cierra lo tuyo primero, la clase esta aquí y no se moverá

[alphp]

Bueno, después del parón por las fiestas, he revisado las cosas y creo que lo mínimo ya está. Quedarían cosas para pasos posteriores como puede ser modificar la clase Tpv y aumentar y mejorar la documentación. Mi principal pega para proceder al merge es el nombre de las constantes, así que dejo a @ssheduardo la decisión de cambiarlos o darlos por buenos ;P

[ssheduardo]

Tal como lo tiene Redsys con esa mezcla madre mía, bueno yo imagino que uno que recién usa Redsys mirará en la documentación oficial y vera el nombre de cada uno (mezcla Español/Inglés), tal vez convenga seguir su guía para "tenerlo estandarizado" con ellos. Por cierto la otra vez estuve leyendo lo que escribió @rogervila que usará Emuns, la pregunta es, para esa versión 2 que esta preparando usará esas constantes. Lo digo para ver si con este Merge pueda usarlo en la v2 que anda trabajando.

[alphp]

Hice unas pruebas rápidas de Enums (php >= 8) contra clases con constantes (php < 8) y en cierta forma se podría crear una clase que imitase los enums en php-7.4 pero me pareció que era demasiado esfuerzo. Es relativamente sencillo convertir las clases que he creado en enums, de esta forma se logra:

1. Simplificar la conversión del código que use la v1 con la v2
2. Aunque el uso varíe un poco, los nombres son los mismos (si @rogervila decide mantenerlos, claro) por lo que el cambio de versión es muy sencillo
3. La estrategia general con la v2 es romper compatibilidad en favor de otras cosas, por lo que tampoco tendría sentido romperse la cabeza para imitar los enums en php-7.4

No sabemos lo que se tardará en tener una v2 funcional, eso no impide hacer pequeños cambios en la v1 como el modificar la clase Tpv para que use las constantes (para validación y demás).

Antes de Navidad consulté el código publicado de la v2 y no vi ningún Enum, por lo que este cambio solo sienta las bases en cuanto a nombres: es lo que más me ha preocupado desde el inicio, tener los nombres sincronizados con @rogervila

Mi intención es revisar el código publicado de la v2 y crear los Enums y colaborar en lo que pueda para que @rogervila no se coma todo el refactor solo.

Por ejemplo el tema de la documentación y enlaces a Redsys es algo que es totalmente aprovechable y es un gran aporte. También el tema de código de ejemplo para diferentes casos (como la devolución) y tests.

[ssheduardo]

Hice unas pruebas rápidas de Enums (php >= 8) contra clases con constantes (php < 8) y en cierta forma se podría crear una clase que imitase los enums en php-7.4 pero me pareció que era demasiado esfuerzo. Es relativamente sencillo convertir las clases que he creado en enums, de esta forma se logra:

1. Simplificar la conversión del código que use la v1 con la v2
2. Aunque el uso varíe un poco, los nombres son los mismos (si @rogervila decide mantenerlos, claro) por lo que el cambio de versión es muy sencillo
3. La estrategia general con la v2 es romper compatibilidad en favor de otras cosas, por lo que tampoco tendría sentido romperse la cabeza para imitar los enums en php-7.4

No sabemos lo que se tardará en tener una v2 funcional, eso no impide hacer pequeños cambios en la v1 como el modificar la clase Tpv para que use las constantes (para validación y demás).

Antes de Navidad consulté el código publicado de la v2 y no vi ningún Enum, por lo que este cambio solo sienta las bases en cuanto a nombres: es lo que más me ha preocupado desde el inicio, tener los nombres sincronizados con @rogervila

Mi intención es revisar el código publicado de la v2 y crear los Enums y colaborar en lo que pueda para que @rogervila no se coma todo el refactor solo.

Por ejemplo el tema de la documentación y enlaces a Redsys es algo que es totalmente aprovechable y es un gran aporte. También el tema de código de ejemplo para diferentes casos (como la devolución) y tests.

Efectivamente hay mucho que aprovechar con lo que has ido realizando, vamos a ver si nos contesta algo @rogervila para ver que hacemos, más que todo por lo que ha ido avanzando y repartiendo la carga del refactor.

[rogervila]

Hice unas pruebas rápidas de Enums (php >= 8) contra clases con constantes (php < 8) y en cierta forma se podría crear una clase que imitase los enums en php-7.4 pero me pareció que era demasiado esfuerzo. Es relativamente sencillo convertir las clases que he creado en enums, de esta forma se logra:

1. Simplificar la conversión del código que use la v1 con la v2
2. Aunque el uso varíe un poco, los nombres son los mismos (si @rogervila decide mantenerlos, claro) por lo que el cambio de versión es muy sencillo
3. La estrategia general con la v2 es romper compatibilidad en favor de otras cosas, por lo que tampoco tendría sentido romperse la cabeza para imitar los enums en php-7.4

No sabemos lo que se tardará en tener una v2 funcional, eso no impide hacer pequeños cambios en la v1 como el modificar la clase Tpv para que use las constantes (para validación y demás). Antes de Navidad consulté el código publicado de la v2 y no vi ningún Enum, por lo que este cambio solo sienta las bases en cuanto a nombres: es lo que más me ha preocupado desde el inicio, tener los nombres sincronizados con @rogervila Mi intención es revisar el código publicado de la v2 y crear los Enums y colaborar en lo que pueda para que @rogervila no se coma todo el refactor solo. Por ejemplo el tema de la documentación y enlaces a Redsys es algo que es totalmente aprovechable y es un gran aporte. También el tema de código de ejemplo para diferentes casos (como la devolución) y tests.

Efectivamente hay mucho que aprovechar con lo que has ido realizando, vamos a ver si nos contesta algo @rogervila para ver que hacemos, más que todo por lo que ha ido avanzando y repartiendo la carga del refactor.

Hola @ssheduardo y @alphp, De momento no puedo trabajar en la V2, así que creo que lo mejor es trabajar de momento en esta PR y, en cuanto retome el desarrollo de la V2, convertir las constantes en enums y aprovechar el trabajo hecho en esta PR.

[ssheduardo]

claro sería lo mejor para poder aprovechar eso.

[ssheduardo]

@alphp se me fue hacer el merge, este finde que este desocupado lo realizo.