#10440 Digamos que tienes 3 clientes,
El primero, al tipo de contrato 0, lo llama: 'indefinido'
El segundo, lo llama: 'sin limite de duracion'
El tercero, lo llama: 'el contrato de nunca acabar'
Como vais a implementar eso?
Simplemente te pongo este caso, pq has dicho anteriormente que cada cliente puede llamar a cada tipo de contrato como ellos quieran.
EDIT: despues del edit en #10440 ya no se si tiene mucho sentido esto xD
#10441MisKo:Como vais a implementar eso?
Eso no se implementa porque en España no existe el contrato indefinido. Problem solved.
#10441 He actualizado. Esto es una API, con su especificación. Ahora nos entendemos mejor?
No tienes razón, te lo está diciendo todo el mundo, y tú sigues a lo tuyo. Has malinterpretado lo de "mostrar los datos es cosa de la presentación". La presentación se encarga de formateos y aspectos visuales, nada más. Por ejemplo si tú tienes un nombre guardado en backend que es:
Mr. Big Dick
La presentación decide como mostrar el nombre, que puede ser:
Mr. Dick
Mr. Big
Big Dick
Dick, Big
El nombre tiene que estar completo en back, con las 3 partes, luego la presentación decide como mostrarlo, pero los datos ya tienen que estar ahí.
El problema principal viene de que por lo visto él llama back y front a cosas que no son back ni front.
Si, para terminar de cerrarlo, es básicamente que el hace una API y, quien la use, que se busque la vida xD
#10448 la cosa es que llamará a getContratos y obtendrá algo así como
0:indefinido
1:temporal
2:obra y servicio
Y ya cada uno que le ponga el nombre que le salga del cimbrel.
#10449 Básicamente, él en su servicio tendrá el listado de contratos que devolverá y, el que implemente la API, ya hará el select como le salga del rabo asegurándose de que, a la API, le devuelve uno de los tipos de contrato que ha recibido.
El problema ha venido en que lo ha explicado como 2 partes dependientes una de la otra, cuando la realidad es que no tiene nada q ver una cosa con la otra xD
Pero solo te devuelve un código que identifica la canción, la letra y la música la pones ya en el front
#10452 La estoy haciendo junto a un tío. Yo me encargo del backend y él del front end. Los dos somos novatos (aunque él tiene mas experiencia en lo suyo se supone).
Usamos spring (no sé cuan buen idea es eso para el front end, pero weno) y le he facilitado una libreria de pojos para que la utilice en nuestra comunicacion cliente-servidor. Total, que tenemos unos selectores en forma de lista y por lo que se ve o bien no le sale de los webos o es así de inútil, que no es capaz de personalizar ese selector sino que usa directamente el enum de los pojos antes mencionados. Se supone que la pagina tiene que ser multi lengua, entonces va y me pide que haga yo las traducciones de los enums xD. Hace uso de tymeleaf, que te vincula el formulario directamente con el pojo, de ahí mi comentario de que no le sale de los webos trabajarselo. O me equivoco?
A ver cuando se dará cuenta que los enums son enums, que van en mayusculas y con guoines bajos, a ver si eso le gusta al cliente...
Luego decís que JS es una mierda, normal, si llegas y te encuentras una lista enorme con enums random y traducciones para todo en un array megatocho, darían ganas de matar a los que hicieron eso.
Lo que no se es donde aparece que el tío que conecta con la API pinte en JS xD
<ul class="menu">
<li v-for='opcion in traducciones.menu'>{{opcion}}</li>
</ul>
<div v-for='(tipo,index) in traducciones.contratos'>
<p>{{index}} es: {{tipo}}</p>
</div>
