Sobre el autor: José Antonio Fuentes, Front-End Developer en VSN
Jose Antonio Fuentes trabaja como front-end developer en VSN. Actualmente su trabajo se focaliza en el desarrollo de las partes front de VSNExplorer y VSN NewsConnect, pero ha participado en proyectos con otros productos como VSNLivecom durante sus seis años en la compañía. Graduado superior en Desarrollo de Aplicaciones Informáticas, cuenta con 13 años de experiencia laboral en los que no solo ha estado ligado al sector Broadcast and Media, si no que desarrollado multitud de proyectos, desde radares para posicionar aviones en un aeropuerto, hasta sistemas de comunicación militares y Big Data.
En el equipo de desarrollo de VSN estamos más que familiarizados con los datos. Para nosotros son el caballo con el que un domador debe trabajar. El animal tiene una fuerza tremenda, pero esa potencia desbocada puede ser un problema. Con los datos nos pasa lo mismo: podemos tener una gran cantidad de información, pero es mucho más valiosa cuando podemos operar con ella aplicando reglas programadas por el usuario que le otorgan sentido.
En VSN siempre queremos ir un paso más allá en la innovación de la tecnología de metadatos. Por ello, hemos trabajado en la creación de un editor de reglas para aplicar a los metadatos generados por nuestros assets en VSNExplorer. Este sistema se compone básicamente de un sencillo lenguaje de programación propio que permite a nuestros clientes crear y gestionar de manera rápida múltiples operaciones con los datos, como si de una hoja Excel se tratase. De este modo, los usuarios pueden aplicar una serie de condiciones como ocultar o mostrar los campos, exhibir el resultado de operaciones aritméticas o cambiar los valores seleccionados dependiendo de otros campos, que les ayudarán en la gestión de media.
¿Cómo sería un editor de reglas ideal?
La interfaz del editor debe ser accesible y fácil de usar para simplificar las operaciones de nuestro cliente cuándo esté programando sus propias reglas en su sistema MAM, no queremos añadir complicaciones. Por ello, en VSN hemos desarrollado una interfaz sencilla y visual para nuestro editor de reglas en VSNExplorer. Mientras programamos reglas para cada plantilla de assets, esta herramienta nos ofrece resaltado y coloreado de sintaxis para una mejor comprensión visual del código que estamos escribiendo. Asimismo, cada elemento del lenguaje de reglas tiene asignado un color para facilitar la comprensión del código. Por ejemplo, los operandos aparecerán en verde en nuestras pantallas y el momento de ejecución en rojo.
Otro elemento que facilita el trabajo a la hora de crear estas reglas es el autocompletado de términos. El sistema realiza sugerencias según se escribe el código, evitando la posible introducción de errores y reduciendo el tiempo de redacción de las reglas significativamente.
Una vez que el usuario ha escrito el código de las reglas, puede compilarlo (como el código de cualquier otro lenguaje). Una vez compilado, el editor indica si existe algún error de sintaxis. De este modo, el usuario podrá acudir a la columna y línea dónde se recoge el fallo y corregirlo de manera sencilla.
Aparte, el editor de reglas ayuda a tener un catálogo de scripts intercambiables entre instalaciones diferentes. El usuario puede exportar el código a un fichero para trasladarlo y trabajar en otro editor. Además, como medida de seguridad y flexibilidad, el sistema permite deshabilitar las reglas creadas de forma temporal o permanentemente, según las necesidades operativas de los assets del cliente en esos momentos.
Un lenguaje para controlar a los datos
En VSN éramos conscientes de que la sintaxis del lenguaje de reglas debía ser muy sencilla. En el equipo de desarrollo queríamos crear un lenguaje para que cualquier usuario de VSNExplorer pudiese comenzar a generar sus propios scripts en minutos. En las siguientes líneas, vamos a explicar cada elemento del lenguaje de reglas.
1. Los valores primitivos: Cómo en la mayoría de lenguajes de programación, son los datos más básicos que manejamos y que encontramos o introducimos en nuestros assets. Son la base de nuestro edificio. Hablamos de números enteros (ej. “-123, 4837”), números reales (ej. “382.4344”, “-948.32”), elementos booleanos (ej, “true”, “false”) y textos, que en nuestro lenguaje técnico se definen como cadenas (ej. “VSN”, “John Smith”).
2. Los operandos: Subiendo un nivel más, encontramos los operandos. Al contrario que los valores primitivos de nuestros formularios, no podemos definir nuevos operandos sobre la marcha, sino que vienen definidos según los campos de metadata que tenga la clase de asset con la que estamos operando. Los operandos se definen con un identificador encerrado entre corchetes. Por ejemplo, el nombre de usuario se define como “[userName]”.
3. Sentencias: Escalamos hasta el tercer nivel con las sentencias, que son el encaje de las dos primeras piezas de nuestro puzzle. Sencillamente, las sentencias son las operaciones que realizamos con valores primitivos y operandos. Veamos dos ejemplos:
En el primero, queremos definir que el nombre de usuario es Antonio. En este caso, el operando vendría definido entre corchetes por [userName]. Para definir el nombre, introduciríamos un valor primitivo que se definiría como “Antonio”. La sentencia se crearía usando el símbolo igual, que asigna ese valor al operando: “[userName]=Antonio”.
Compliquemos un poco más el segundo ejemplo. Cómo ya hemos dicho, podemos realizar operaciones con operandos y valores primitivos. Imaginemos que queremos multiplicar por diez el precio de un producto. La sentencia daría valor al operando [tenProductsPrice], que recogería la multiplicación por diez de cada del operando que define las unidades [unitPrice]. Sería así: “[tenProductsPrice]= [unitPrice]*10” Pero claro, todo este lenguaje de código puede sonar muy abstracto y no podemos saber que es cada cosa cuando abramos el editor. Para ello, hemos definido el siguiente elemento del lenguaje.
4. Comentarios: Todo lenguaje de programación que se precie debe permitir añadir comentarios para clarificar para línea de código. El editor de reglas de VSN permite comentar fragmentos del código introduciendo “//” en comentarios de una línea o /* y */ para comentar varias líneas. Volviendo al ejemplo anterior con Antonio, y recogiendo todas las operaciones, quedarían expresadas así:
5. Bloques de control: Ahora nos toca arremangarnos. Si están familiarizados con los lenguajes de programación, saben que el código es como un río que en ocasiones se debe bifurcar dependiendo de ciertas condiciones. Éstas se definen añadiendo bloques de control. En nuestro editor se realizan con las sentencias if…else.
Imaginemos que queremos definir cuándo debe aparecer el campo DNI o el campo CIF en nuestro formulario. La expresión con comentarios de esta operación sería:
6. Momentos de ejecución: Vamos con el sexto ingrediente en nuestra coctelera de programación. Con los momentos de ejecución definimos los tiempos en que queremos que cada porción de código se ejecute sobre nuestros datos. En ocasiones nos interesan que se ejecuten al abrir el formulario del asset, otras mientras operamos o, incluso, nada más cerrarlo. En nuestro lenguaje hemos definido los siguientes:
- OnOpen: se ejecuta nada más inicializar el formulario del asset.
- OnEdit: este momento se ejecutará cuando se comience a editar el formulario.
- OnChange([operando]): permite ejecutar código cuando cambia el valor de un operando.
- OnClose: el código que haya en este momento de ejecución se lanzará nada más cerrar el formulario.
Si usamos nuestro ejemplo anterior y queremos que esa regla se ejecute al inicializar el formulario del asset, tendríamos que definirlo con el momento de ejecución OnOpen, que se definiría así:
Metadatos controlados y más automatización para nuestros clientes
Con el nuevo editor de reglas, nuestros clientes y usuarios tendrán la capacidad de automatizar muchas operaciones con datos. Por ejemplo, imaginemos que tenemos los campos «total año pasado» y «total año actual», y que queremos que se muestre un campo con la suma de ambos. Podemos crear una regla para unir esos dos valores separados y guardar un dato general bajo el nombre “total general”.
Asimismo, pensemos en un cliente que cuenta con el campo «id externo», que se rellena normalmente por un workflow. Pues gracias a las reglas, dicho campo se puede marcar como de sólo lectura. De forma que los usuarios ya no puedan modificarlo por error. También podemos activar un campo «cumplimentado» automáticamente, cuando un usuario introduce contenido en otro campo.
Desde el equipo de desarrollo de VSN sabemos que esta característica puede marcar un antes y un después en el uso de VSN Explorer. Es por ello que seguimos trabajando para mejorar y llevar a todas partes de la aplicación esta potente herramienta.
Suscríbete a nuestra newsletter para estar al tanto de todas las noticias