Cosas de JavaScript


([N3] pacosatu) #1

Hola.

El otro día os planteaba lo peligroso que puede llegar a ser que el editor de fórmulas evalúe las expresiones Javascript en vDevelop, ahora he descubierto que también las evalúa la opción Recalcular Errores.

Hoy he tenido otra mala experiencia (y ya van varias con la 7.15) que quisiera que me confirméis antes de trasladarlo a soporte. Yo estoy en la parte derecha de la campana de gauss y no quiero ganarme el título de tocapelotas.

Por favor comprobad lo siguiente:

Tenemos un proyecto de datos Proyecto01.dat con la tabla PERSONAS y el siguiente fichero JavaScript JS_AñadirRegistros.js que ejecutamos en 3P y añade un registro:


var oRegistro = new VRegister(theRoot)
oRegistro.setTable(“Proyecto01/PERSONAS”);
var nuevaTrans = false;
var hayTrans = theRoot.existTrans();
if ( hayTrans == false ) { var nuevaTrans =
theRoot.beginTrans( ‘Añadiendo registros a la tabla PERSONAS’ )};
oRegistro.setField(‘APELLIDO’,‘SATUÉ’)
oRegistro.addRegister()
if ( nuevaTrans ) { theRoot.commitTrans(); };

Ahora cread una Solución nueva con otro proyecto de datos Proyecto02.dat. Copiar la tabla PERSONAS y el fichero JS_AñadirRegistros.js

Ahora ejecutar de nuevo JS_AñadirRegistros.js en 3P sin tocar nada del código. Veréis que hay un error ya que oRegistro.setTable(“Proyecto01/PERSONAS”); hay que cambiarlo por oRegistro.setTable(“Proyecto02/PERSONAS”);

Este error en mi caso provoca que el servidor de pare, sí, el servicio VATP del vServer se para, como siempre y es gravísimo, lo hace silenciosamente y sin gritos.

Hay que decir que en 1P el código se ejecuta sin error y aparece una transacción terminada y vacía.

Conclusiones:
Yo ya expresé en su momento que gestionar las Referencias a los objetos de Velneo en JavaScript mediante LITERALES trae problemas de mantenimiento y detección de errores. Solo hay que ver el procedimiento de adaptación del módulo de personalización del nuevo vERP a nuestras aplicaciones.

Solución temporal:
Volver a las prácticas ancestrales de creación de código, es decir, comprobar errores constantemente:


oRegistro.setTable(“Proyecto01/PERSONAS”);
if (oRegistro.tableInfo().idRef().length == 0) {
lError = true
theRoot.setVar(‘CERROR’,‘La tabla PERSONAS no es accesible’)
}

Simplemente quiero con este ejemplo hacer ver la pérdida de funcionalidades que tenemos respecto a la Depuración de código cuando usamos JavaScript. Velneo nos acostumbra mal porque está muy asistido, pero en JavaScript tenemos que descambiar el chip.

Nos os olvidéis de comprobar este posible bug.
Saludos
Paco Satué


([N2] ramiro) #2

Gracias, Paco:

La refactorización de identificadore que V6 hacía en su momento creaba, por si misma, la diferencia a favor respecto a otros entornos.

La refactorización de V7 tardó en estar completa pero ahora funciona razonablemente bien. El problema es que desde hace varias versiones V7 evoluciona fundamentalmente basándose en JavaScript. Eso también crea la diferencia, esta vez en sentido inverso.

Dicho de otra forma V7 ahora crece en dirección “tfos si efiL”

Esperemos que hagan algo al respecto.

Saludos. Ramiro


([N4] ns) #3

+1


([N3] pacosatu) #4

Hola Ramiro.

Yo la verdad que la refactorización no la he echado de menos nunca en otros entornos, ya que teníamos otras herramientas igual o más potentes. Yo pensaba que lo de la refactorización era otra cosa.

De todas formas, si el código que he puesto (de lo más simple que hay), es capaz de tirar el servicio VATP, habrá que mirar más en serio lo de la estabilidad del vServer.

Saludos
Paco Satué


([N2] ramiro) #5

Buenas tardes, Paco:

Hace cosa de un año envié a soporte un par de ejemplos de código JavaScript que tiraban vServer. Uno de ellos, si no recuerdo mal, era la ejecución de una sentencia que cambiaba el aspecto del cursor (cosa que no tiene sentido ejecutar en 3P, pero lo cambié sin darme cuenta…).

Me costó un disgusto porque las malas noticias parecen no ser bienvenidas en Velneo. No obstante aprendí dos cosas: 1) JavaScript debe estar confinado a las tareas imprescindibles y 2) Cuando descubres y comunicas un problema quedas expuesto tu, no el problema.

Saludos. Ramiro


([N1] aztecmexico) #6

Hace mucho tiempo (bueno, en nuestros términos) Alfonso publicó esta entrada en el blog, creo que fué muy clara para su momento.

http://velneo.es/que-es-javascript/

De ahí pongo énfasis en este párrafo:

¿Programar en JavaScript es mucho más lento?

Por supuesto, JavaScript es un lenguaje orientado a objetos,basado en prototipos, imperativo, débilmente tipado y dinámico, por eso no recomendamos usarlo salvo en sitios estratégicos, específicos y rentables.

Pudiera existir una contradicción actualmente, toda vez que se ha potenciado mucho la API vJavascript, la elección de programar todo en vJavascript o en V7 es de cada quien, con los riesgos que cada cosa conlleva, ojo, habrá proyectos que no hay de otra más que con vJavascript, y ahí pues a ser super cuidadosos.

Lo que si, yo no me enojaría si en Velneo se enojan porque les descubres o reportas un fallo grave, me vale, yo cumplo con avisarle a ellos, y, si, a la comunidad para evitarle dolores de cabeza, no me molesta lo que piensen de mí o si me encasillan como rompebolas u otra cosa, aparte de enojarse lo tienen que arreglar, tarde que temprano, jajajaja. YO SEGUIRÍA REPORTANDO TODO LO QUE ENCUENTRE y que creo y considero puede generar problemas, les guste o no.

Saludos.

Martin Ibarra.

P.D. Es una de las consecuencias de tener trato directo con los responsables de Velneo, lo cual, a mi parecer es no bueno, es EXCELENTE. Digo, Oracle, Informix, DB2, MicrosofT y demás NUNCA ME PELARÁN, nunca tendré el trato ni los pleitos que con V7, y aparte los gigantes hasta me cobran por hablarles, algo así como mínimo 3000 dólares por año por 12 incidencias por mail, digo, eso que hace Velneo de ser tan abiertos no lo hace nadie más, y menos gratis. Solo es mi punto de vista.


([N3] pacosatu) #7

Hola Ramiro.

Me da igual el comando que se use. El vServer es como el Santo Grial, utilizando una expresión ya usada hace poco, debe ser protegido con n-capas que eviten su caída por cualquier comando fuera de contexto o con parámetros erróneos. Otra cosa es que yo abra una transacción infinita o que haga FORMAT C:\windows*.*.

Una instancia es una instancia y punto. Un simple comando en esa instancia no puede tirar el vServer en el que puede haber 100 usuarios conectados.

Si hay que comprobar 200 clases y 1500 funciones de javascript en 1P, 2P y 3P (podemos coger un becario para estas cosas) pues se comprueban, antes de asegurar que un producto es altamente estable.

Cualquier aplicación estable del mercado funciona de por vida si no se toca o cambia su entorno. La diferencia está en lo que hemos tardado en conseguir que sea estable y la sensibilidad a los cambios.

Martín.
Me has pillado terminando este rollo.

Por supuesto que me tiene despistado esa dualidad entre Velneo nativo y/o asistido y lo que se transmitió en LifeisSoft 2014 donde se dieron ¡Vivas! a la personalización con Javascript y se dijo que no habrá de momento más objetos Velneo, sino que primero aparecerá toda la potencia gráfica en forma de API y luego ya veremos.

Ya casi hemos matado el QML por ser complicado de aprender y poco intuitivo (solo hay que ver lo nada presente que está en el foro y en los blogs de velneo).

Yo no quiero matar el API por ser inestable, lento y dificil de mantener. Me parece una funcionalidad casi imprescindible porque hay muchas cosas que no se pueden hacer con Velneo (a mí me parece una aberración de la plataforma) y hay que hacerlas irremediablemente con JS.

Yo también valoro y mucho el contacto directo (incluyendo copas y comidas) con los responsables máximos de la plataforma. De lo contrario no estaría perdiendo el tiempo en el foro. Eso sí, intento siempre documentar los fallos con ejemplos y proponer en la medida de lo posible alternativas mientras se soluciona el tema.

Saludos
Paco Satué


([N4] Ramon Denuc) #8

Paco 100% con tu comentario.


([N1] Spicer) #9

En mi opinión, si te transformas en un tocapelotas, problema de ellos y no tuyo. Mientras más apoyo haya de la comunidad en orden a exponer falencias o inestabilidades del sistema, tanto mejor.

Mi impresión es que la comunidad está empezando a exigir a Velneo ciertas cosas que quizá inicialmente no estaban contempladas, y en este contexto, la API de JavaScript no ha obtenido el tratamiento depurado y riguroso que debiera, si el objetivo es crear una plataforma que sea poderosa y estable con altos porcentajes de código escritos en JS

Saludos,


([N4] Infortic) #10

estoy con Paco al 100%

Estoy haciendo bastante código con js, y a mí, me parece tremendamente fácil tirar abajo el vServer, cualquier instrucción que intenta acceder a alguna tabla o variable, y tienes mal el proyecto o el nombre de la tabla, es susceptible de tirar abajo el vServer entero, amen de cualquier operación de bbdd sin transacción abierta, y otras muchas cosas que me han ido pasando como las caídas de transacciones largas si no usas la función ClientEntertainer, funciones de js que directamente no funcionan…

No es algo puntual, en mi día a día con js tengo caídas del vServer, y sí, me parece increible que un servidor de bbdd “serio”, con datos que pueden ser críticos se caiga con cualquier instrucción de tres al cuarto, lo peor es que en la mayoría de casos no da ninguna información, simplemente se cae, así que sin debugger, ya se sabe, a poner 100.000 alerts o logar en una tabla hasta que encuentras la instrucción que falla, y en el proceso unas cuantas caídas de vServer te vas a llevar.


([N4] ns) #11

+1


([N4] alfonsogu) #12

Hola a tod@s, como dijo un genio al que admiro especialmente

Existen dos tipos de lenguaje de programación: por un lado, aquellos de los que la gente se queja todo el rato; por otro, los que nadie utiliza. Bjarne Stroustrup

Una queja es un regalo, si quieres que la gente te regale la oreja dedícate a otro negocio, eso lo tengo claro y lo expresé cientos de veces en este foro, en el blog y otros medios. Hay que agradecer y escuchar siempre para poder luego tomar las mejores decisiones.

Sobre el asunto de vJavascript, siento que se necesita un seminario con la comunidad para trasladar nuestra visión presente y futura sobre vJavascript.

Por tanto me apuntó organizar un evento de este tipo para este verano, donde podamos charlar y debatir sobre este asunto en comunidad!

Un saludo y muchas gracias a tod@s