Estoy en un proyecto junto con otro tio. 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...
/rant mañanero
#10411 Hombre la composicion de la lista y la traduccion es backend, siempre y cuando la informacion no sea trivial.
#10415 Hablamos de listas basadas en enums. Por ejemplo, tengo un enum de tipos de contrato: indefinido, parcial, practicas. Como digo, ese enum esta en la libreria que he compartido con él, no es un endpoint a consultar. A mi me da igual lo que él muestre por pantalla (son dos proyectos: cliente y servidor) mientras yo reciba ese enum. Es responsabilidad suya como representarlo, no mía. O no?
#10416 Yo creo que sería responsabilidad tuya, en algún sitio del servidor deberías de tener las traducciones o, por ejemplo, una tabla con tipos de contrato válidos: tipo | nombre_es | nombre_en
Es verdad que es un campo muy simple, pero si el día de mañana quieres agregar un nuevo tipo de contrato, eliminar alguno existente o cambiar el nombre de uno de ellos (el 'contrato en prácticas' pasa a ser llamado 'contrato de estabilidad sospechosa'), lo ideal sería que simplemente cambiándolo tu ( ya sea agregándolo en la base de datos o devolviendo adicionalmente el nuevo elemento o lo que sea), ya aparezca en el front, sin necesidad de tener que tocar nada de este.
En el FRONT simplemente se iteraría la lista que recibe desde el back
#10417MisKo:cambiar el nombre de uno de ellos
Tú mismo lo has dicho. Eso es decisión del front. Puedo tener varios clientes y cada unos ponerle el nombre que quiera, no seré yo quien provea como quieren representarlo cada uno de ellos ni que lo vaya actualizando cada dos por tres.
Pero yo creo que confundís con que el cliente hace una peticion al servidor y no es así. Simplemente usamos unos POJOs, y el frontend tiene rellenar unas listas con unos enums, punto.
#10421 explícanos cómo harías desde el front que cada cliente pueda llamar de una manera a un tipo de contrato.
#10422 ni zorra. Pero se que las listas tienen un valor y un texto representativo de ese valor. Yo puedo decir que el primer elemento tome por valor el 0 y que se muestre "Indiferente"
Porqué las aplicaciones de la seguridad social, hacienda, firmas digitales, contratos... están en Java y requieren IE para funcionar? Los programadores de AEAT son unos troles, unos inéptos o ambas cosas? Pregunto
#10427 Sale un loader muy bonito (y no he visto más, pq despues de 30 segs, seguia el loader xD)
EDIT: that doble post xD
#10421 A ver, que si quieres llevar la razon y no haces caso a las otras otras respuestas, no pasa nada, pero la lógica dicta que toda esa información viene desde el back.
Si, además, cada cliente puede cambiar esos nombres como les de la gana, razón de más para tener una tabla con los nombres asociados en el back por id de cliente.
Pero vamos, no soy super entendido de java (y lo mismo lo que digo es una tonteria), pero igual tu idea es compilar lo que hay para el cliente 1, cambiar los nombres de los contratos y compilar para cliente 2, cambiar los nombres de nuevo y compilar para cliente 3... creo que lo otro es más mantenible y, el día que haya que hacer algun cambio, no tienes que recompilar
#10428
Pues eso es solo el comienzo de lo mala que es la web. XD
Cuando buscas una parada de bus:
http://www.emtmadrid.es/Estimaciones/Estimaciones.aspx?data=EBYFjlVvgmWzx0b6hcS%2bP8isSS67ORoWtKXWsMKpf7wwLyCtzNVMoEGR%2fz%2bN9wz5NkNbXleZzAh4O4c8fRMRhkBVMlwvKHoXJIqIRke6obBSZ5hUp9uTB6XT3z1dXn16%2f7EZEaAcV23C0O9O7Evi6HUsCVlc%2fIfitfraweB7O3yfdDt1MhMwMaMdV4CrMFaaO45EUHStef4sPZtjKVM6d78%3d
Todavía están en 2015. En enlace del logo de "EMT Madrid", que supuestamente lleva a la página principal, no funciona. Los enlaces de redes sociales te abren una nueva pestaña que muestra la misma página. Es un desastre.
#10430 Lo que me hace gracia es que entras y sale un loader enorme. Al rato que ha cargado el loader, aparece la web con... otro loader en el centro (el del slider y ese lleva ya facilmente otros 40s)
EDIT: nada, han pasado 2 minutos y el slider no carga, solo su loader xD
EDIT: Por cierto, al buen input hidden xDDD
#10431 no paran de hacerse requests a esto
http://www.emtmadrid.es/getdoc/54d115ae-7a1d-4407-a862-0ba1f28c957e/default.aspx
pobre server xD
#10416 bajo mi punto de vista el front no debería tener esa responsabilidad. Es el back quien debe proveer esa información y el front simplemente iterarla para mostrarla de una forma u otra.
#10436 Yo entiendo que, tal y como lo ha descrito, hay otro proyecto en java que genera el HTML final, y a esa programacion (en java) el lo llama front por el simple hecho de generar el HTML que vería el usuario
Partiendo de esa base, si podría programar cosas en el front para generar el HTML final de una manera u otra, pero independientemente de eso, la información que comenta debería de venir desde el 'servidor'
#10437 #10423 No se dices que la informacion puede cambiar por cliente, eso en mi libro es informacion no trivial.
De hecho usar un ENUM si vas a personalizar luego lo que se muestra/asocia no lo veo yo una muy buena idea.
El frontender nunca tiene responsabilidad sobre los datos que recibe, no puedes mandarle VAL_1, VAL_2, VAL_n y esperar que el haga la personalizacion para cada cliente o decida el valor a mostrar, eso es claramente backend.
Lo unico que le podrias pedir es personalizar el como se ve el elemento, pero vale.
Si hablasemos de un selector, Si/No, Hombre/Mujer esta claro que defines un valor trivial (1/0, H/M, etc) y luego lo mantienes en el backend.
#10438 Sin pensarlo mucho, por un lado deberia de haber una tabla con los tipos de contrato (id,nombre), otra con los nombres de cada uno de esos contrato en los distintos idiomas y agrupandolos por cliente (id,tipo_contrato_id,cliente_id,nombre_es,nombre_en), y luego una tabla de contratos en la que, el tipo_de_contrato, fuera el Identificador de la otra tabla. (id, tipo_contrato_id, resto_datos_contrato... )
Eso creo que sería lo lógico y, al front, pasarle simplemente los tipos de contrato con el nombre que le toque segun cliente e idioma xD
Dejarlo, ya nos hemos arreglado tal como comentaba en #10423. Parece que me explico como el culo xD.
#10438 Yo no he dicho de cambiar los enums, sino su REPRESENTACION.
Ejemplo:
Lista elemento 0 - PRACTICES - "Practicas"
Gracias de todas formas.
#10439 Cuando hablaba de clientes me refería a distintas aplicaciones cliente (web, movil, de terceros, etc) que van atacar el web service (mi parte).
