#27271 yo? Nada. Leí hace tiempo sobre las limitaciones que puede tenert un JSON y como lo solucionaban los protobuffers y de ahí llegue a grpc, la evolución de las api rest. A mi me parece la polla el concepto, lo pregunto por si lo conocíais y qué opinión tenéis xD
No hay que promover estas mierdas automatizadas que nos quitan el trabajo, lo que hay que hacer es automatizar los trabajos de los demás.
#27273 espero que no uses transporte publico/vehiculo porque le estas quitando trabajo a mi caballo y si usas un smartphone aun eres peor porque te estas cargando todo mi sector de palomas mensajeras, asi que deja de automatizar cosas y automatizanos de ti!!
Ya que aquí sois bastantes los que trabajais con front end, a ver que os parece ésto que me pasa en el curro:
Típica aplicacion (de uso en red local solo) de webservice + webapp. Yo hago el ws con Spring Boot y otros la web con Angular, la cual va obteniendo datos y delegando el trabajo al webservice. Pues bien, resulta que ellos no hacen "modelos" de los JSON que envian/reciben, sino que a pelo para simplificar y reducir la carga. Yo obviamente sí uso modelos, usando Jackson (es la eleccion por defecto con Spring Boot aunque se puede cambiar).
Cosas absurdas que me piden:
-Incluir siempre todos los campos de mi modelo json, aunque éstos sean nulos { "campo" : null }. Eso en el caso de campos primitivos.
-Pero en el caso de objetos anidados, que éstos esten inicializados. Es decir: {"objetoAnidado": { "campo1": null} }
El primero punto aunque no me guste, no hay problema pues configuro el jackson para que lo haga y ya. El problema viene con lo segundo que me piden. No he indagado demasiado pero diria que jackson no tiene tal opción, lo cual me obligaria a mi, a inicializar en java todos los objetos anidados. Una chapuza de cuidado vamos.
Es algo normal lo que me piden? Qué solucion le veis? Cómo lo deberian de hacer realmente los de front end?
Por cierto, no existen librerias en angular para tratar con los json? Porque ellos los parsean a mano diria.
#27275 Entonces fuistes tu que hicistes que tu caballo destruyera mi coche y tus palomas se cagaron en mi movil como los pille los destruyo 
#27277 Diles que pueden comprobar si una clave existe en un JSON, porque me da que lo que hacen es acceder directamente y comerse el error con patatas xD
#27277 La primera es una convención, jackson lo soporta y puede llegar a ser hasta normal.
Pero respecto a la segunda, yo diría rotundamente que no... Te están obligando a instanciar siempre... aunque estos sean nulos.
Además que no tiene sentido, ya que no es lo mismo una referencia nula... que instanciar una clase con todos sus campos a null.
Como ya te han dicho por ahí, a ellos les debería dar igual porque deberían comprobar que una key exista antes de acceder a ella, si no la de petes en runtime con js que se pueden comer...
#27277 Lo que te dicen, los vagos no comprueban antes de intentar acceder, por lo que se estarían comiendo mil petes.
Es problema suyo, no tuyo
#27277 Y por cierto, si al final te obligan a hacerlo, lo puedes hacer usando Jackson también eh.
https://stackoverflow.com/questions/45565848/jackson-serialize-null-object-as-empty
#27279 sí exacto, lo que hacen es ir al valor del campo directamente, sin comprobar si existe primero. Ya que si lo hacen les queda un codigo bastante feo y chungo segun me decian... porque ellos se pensaban que yo siempre les devolveria la misma estructura de json. En fin, a ver como queda.
#27282 supongo que sí, el problema viene cuando haces que la api acabe adaptandose a la web. Que en prinicpio se decidió de hacer la api precisamente porque pudieran haber futuras aplicaciones que la usarian.
#27278 ya puedes empezar porque tengo un ejército de palomas listas para cagarse en tu movil y en tu colección de porno y no hay bateria o enchufe que te salve!
#27283 mire por donde se mire te piden algo absurdo, no tienes que construir el objeto que envías con propiedades vacías si estas no existen, su trabajo es validar los datos que reciben.
Crees que lo has visto todo hasta que llegas a una reunión y el informático del cliente te dice que por qué tú eres el servidor en una aplicación cliente-servidor y el servidor no es él, que eso depende del punto de vista.
Alguien tiene por ahí algo de documentación de como integrar una clase Junit test case con AbstractTransactionalJUnit4SpringContextTests?
Estoy buscando qué beans y dependencias he de incluir para hacerlo funcionar correctamente, pero todo es muy confuso.
#27290 fue de hace varios meses esa reunión, pero recuerdo que giré la cabeza y seguí hablando con el cliente, obviando completamente esa pregunta del informático. En plan así xDD
#27297 y lo vas a saber tú.
tengo una ristra de catálogos y necesito hacer sus correspondientes JUnit, podría hacerlos con Selenium que me resultaría mucho más fácil, pero bueh, para hacer tests de servicios es mejor algo como AbstractTransactionalJUnit4SpringContextTests, supongo.
#27298 No sé por qué has de usar esa clase en concreto, pero bueno, mira a ver si esto te sirve, porque con la descripción que das, no es que se te pueda ayudar mucho:
https://www.springbyexample.org/examples/simple-spring-transactional-junit4-test-code-example.html
#27299 aquí todos los usan donde curro, y me veo obligado a usar esa clase sin tener mucha idea de como configurarla e intergrarla ni que jars(entre los propios que utilizan y algunos propios de spring) necesita para que funcione. La cosa es que me pasaron ejemplos, porque no puedo partir desde 0 conocimiento a hacer algo funcional. Las clases test no son como el ejemplo que has pasado pero como las tengo "deberían funcionar", mi problema es con los context.xml y me estoy pasando algo por alto, algún jar que me falte definir su bean.
Pero bueno, seguiré investigando, a ver si encuentro algún context que me valga como ejemplo y comprarar y ver que jars me faltan, y empaparme bien del funcionamiento del componente.
