VJavascript ejemplo cargar plurales

En este artículo vamos a escribir un ejemplo de VJavascript que nos servirá para hacer algo super frecuente en v7: Cargar plurales, pero de forma genérica.

De esta forma podremos aprovechar el fichero javascript para cargar cualquier plural de cualquier tabla. Solo tendremos que crear el objeto proceso en v7 que nos índique cual es la ficha origen y cual la lista destino, y asociarlo con este fichero. Con la salvedad que la lista destino tiene que ser de un histórico de la ficha origen.

Fichero: CargarPlurales.js

// IN.- Ficha
// OUT.- Lista de historico (Cargar plurales en v7 )
// Este proceso puede recibir una ficha de cualquier tabla
// Retornará la lista del historico de esa ficha, que espere a la salida

// Recogemos la información de las dos tablas
var TableInfoEntrada = VRegisterIn.tableInfo();
var TableInfoOut = VRegisterListOut.tableInfo();

var ListOut = VRegisterList;

var NumHist = TableInfoEntrada.PluralCount();

// Suponemos que la numeración de los historicos es de 0 a n-1
for (h= 0; h < NumHist; h++ )
{

if ( TableInfoEntrada.pluralBoundedTableId( h ) == TableInfoOut.id() )
{
ListOut = VRegisterIn.loadPlurals( TableInfoEntrada.pluralId( h ) );

     h = NumHist;
}

}

// Retornamos la lista
VRegisterListOut.append( ListOut );

Controlando el acceso a los datos

Cuando se hacen aplicaciones para empresas, es normal que se requiera controlar los permisos de acceso al programa dependiendo del departamento. En este artículo os voy a explicar como lo hemos solucionado.

La aplicación está pensada para poder ser heredada y aplicarla a aplicaciones de cualquier fin, pudiendo incluso ser usada simultáneamente por más de una aplicación.

Distingo dos niveles de acceso:

1. Acceso a menús
2. nivel de autorización para crear/modificar datos

El control de accesos lo vamos a hacer a nivel de grupos de usuario, aprovechando la tabla que existe en vBase

Por lo que he creado cuatro tablas:

Acciones. En ella se dan de alta las acciones de menú que vamos a permitir activar o bloquear.

Tablas. Donde creamos las tablas que tendrán control de acceso a la información

Grupos – tablas. Donde definiremos los permisos de cada grupo de usuario con las tablas

Grupos – acciones. Para dar o quitar el acceso a las acciones por grupo.

Este es el esquema:

A nivel de acciones de menú no hay mas que dos posibilidades, o se permite o no se permite. Sin embargo en las tablas la cosa se puede complicar mucho (todo lo que queramos), desde controlar alta-modificación-baja, hasta controlar el acceso a cada campo (ver/modificar).

Búsquedas con variables locales

Uno de los grandes cambios entre v6 y v7 son las variables. En la v6 casi todo pasaba por variables en memoria globales, y ahora en la v7 son las variables locales las grandes protagonistas.

Hasta el punto de no recomendar el uso de variables globales, salvo casos muy claros. Esta variables locales, han pasado a ser la forma natural y limpia de conectar valores entre procesos y objetos. Hoy vamos a explicar su uso con las búsquedas.

En las búsquedas se pueden definir variables locales, pero lo primero que nos preguntamos es ¿como les damos valor?.

Bien el caso más habitual es que la búsqueda tenga asociado un formulario, y resulta que todas las variables locales que tenga ese formulario, si coinciden en nombre con variables locales de la búsqueda su valor es enviado a ella. Por lo tanto lo único que tenemos que hacer es crear un formulario con variables locales del mismo nombre.

Vamos a desarrollar el ejemplo: Tenemos una tabla con los índices clásicos:

- ID.- Código

- NAME.- Alfabético

- WORDS.- Palabras

- PARTS.- Trozos

- MOD_TIM.- Fecha de modificación

y queremos hacer una búsqueda que no permita utilizar cualquiera de esos índices. En la búsqueda definimos las siguientes variables locales:

- ID.- Numérica, y nos permitirá buscar un código determinado

- NOM.- Alfabético, texto a buscar por los índices NAME, WORDS o PARTS.

- BUS_TIP.- Alfabético. Esta variable recibirá el tipo de búsqueda a realizar con el texto recibido en NOM. Vamos a permitir 4 tipos (A.- alfabético, P.- todas las palabras, G.- alguna palabra, T.- trozos)

- FCH_ON.- Booleana. Índica que queremos buscar por la fecha de modificación.

- FCH_DES.- Fecha. Fecha desde la que buscar

- FCH_HST.- Fecha. Fecha hasta

vBase. Entidades y categorías

Vamos a ver como  crear clientes, proveedores con la vBase actual.

La tabla de entidades es genérica, y cuando queremos explotarla desde otra aplicación, como pueda ser la contabilidad o gestión, para usos concretos como definir un cliente o un proveedor, se debe usar la tabla categorías y la que las relaciona ENT_CAT.

Lo primero que tenemos que hacer es crear las categorías de uso reservado que necesitemos, la forma escogida es creando una constante que la defina. Ejemplos:

~CLT_CAT@vConta.dat con el valor CLT para definir clientes

~ENT_AGT@Gestión Maestros.dat  con el valor AGT para definir agentes comerciales

A continuación creamos un proceso que ejecutemos al inicar la aplicación para dar de alta las categorías en la tabla CAT

- Ejemplo de proceso

Suponemos que en nuestra aplicación vamos a definir comerciales, para ello definiremos una constante ENT_AGT, con el valor AGT, y creamos un registro en la tabla de categorías tal que así:

Es importante crearla como de uso reservado (USO_RSV = 1 ), para que el usuario no pueda borrarla. Ahora el usuario podrá definir cualquier entidad como comercial, con solo añadir esta categoría a las de la entidad ( tabla ENT_CAT).

vBase definitiva

Con la salida de la versión 7.4 de v7, se publica lo que será la vBase estable. En esta vBase es fruto de la colaboración de Velneo con varias empresas, que empezó con una semana intensa de trabajo.

A esas jornadas, cada uno fue con su propia idea de vBase, y juntos llegamos a esta solución, de la cual estamos muy satisfechos.

Nuestro objetivo principal, incluso antes de ser elegidos para esta colaboración, era diseñar una vBase lo suficientemente abstracta, como para que pueda ser usada con aplicaciones totalmente opuestas (ejemplos: gestión clásica, académias, clubs deportivos,…..). Para ello habíamos empezado a contactar con otras empresas para consensuar ideas. Al ser elegidos para diseñar la vBase oficial, lógicamente, nos volcamos en el proyecto junto con el resto de equipo.

Ya en la v6 nosotros (Guida21), habíamos decidido basar nuestros desarrollos de las plantillas principales de Velneo (vBase, vConta) creciendo en funcionalidades, pero la experiencia de desarrollar aplicaciones para múltiples sectores, nos hacía encontrarnos una y otra vez, con la imposibilidad de tener una tabla de entidades común. Con esta vBase hemos conseguido que esto no nos vuelva a suceder. Hemos sido lo más ambiciosos en los planteamientos que el tiempo y los recursos nos han permitido.

La vBase que se ha publicado será totalmente estable a nivel de datos, es decir ya no desaparecerán campos ni tablas. La vConta se ha diseñado integrandola totalmente con esta, y es el mejor ejemplo de como operar con las entidades desde otras aplicaciones.

Voy a escribir algunos artículos que expliquen aspectos claves de esta vBase. Si quereis que escriba sobre algún apartado concreto me lo podeis indicar.

un saludo.

Hojas de estilo v7 (gdCSS)

Dentro de la v7 podemos utilizar hojas de estilo CSS, para configurar el aspecto de nuestras aplicaciones. Al igual que en la web 2.0 se separa el contenido y el diseño, estando este último en los ficheros .CSS. Entonces lo ideal es que nuestros desarrollos en v7 utilicen esta técnica, de forma que unos nos dediquemos al diseño de los datos y otros al de la estética.

Dado que yo soy de los que diseñan como organizar datos y no soy bueno en definir la estética, he decidido crear una aplicación que permita a los diseñadores experimentar como afectan los distintos estilos a los objetos de una aplicación en v7. De esta forma los diseñadores podrán ir creando trozos de código CSS reutilizable, viendo su resultado y configurando distintas hojas de estilo a utilizar por los usuarios, a modo de plantillas.

Para esto he creado un proyecto de datos, con la siguiente estructura:

Recursos: Función fPregunta

Los que venimos de v6, echamos en falta un función “fPregunta”, que presentaba un cuadro de diálogo standard con un mensaje que le pasabas como parámetro y los botones SI / NO para que el usuario respondiese, y te devolvía el valor 1 o 0 según fuese la respuesta.
Bien, pues en este artículo vamos a diseñar nuestra propia función para preguntar al usuario con su cuadro de diálogo, aunque le vamos a pasar algún parámetro mas, y con todas las posibilidades de crecimiento.

En la función de la v6, sólo le pasábamos como parámetro el texto de la pregunta. En nuestra función le vamos a pasar tres parámetros:
TEXTO.- Texto de la pregunta
TITULO.- Título del formulario
BOTONES.- Este parámetro, nos permitirá indicarle que botones queremos que contenga el formulario. De momento vamos a programar la función para 2 opciones:

S: Botones SI/No
A: Aceptar/Cancelar

Procedemos:

Proyecto de aplicación Recursos

En el proyecto de aplicación Recursos, tendremos objetos como los siguientes:

Dibujos. Dispondremos de los iconos que utilizaremos en las barras de herramientas, en los botones de los formularios (Aceptar, eliminar, cancelar…), y en los menús y sus acciones.

Acciones. Crearemos acciones genéricas de v7, como salir del programa, cerrar ventana, y acciones de listas como filtrar, partir listas, etc… , comandos de ficha, como alta, editar y eliminar (a utilizar en la barra de herramientas de las rejillas). A todas estas acciones les podremos asignar el dibujo que nosotros queramos utilizar, y ya no estaremos sujetos a los que vienen por defecto en la v7, pudiendo cambiarlos cuando queramos para toda la aplicación, de un plumazo.

Menús. En este apartado podremos crear la estructura de menús común a las aplicaciones. Un menú que yo pondría es el menú de contexto de una lista.

Toolbars. Crearemos una o varias barras de herramientas a utilizar en las aplicaciones. Entre ellas tendremos al menos la barra de herramientas genérica que utilizaremos en las rejillas de datos.
De tal forma que en todas las rejillas pondríamos estos recursos como vemos en este ejemplo:

Ahora podremos cambiar las opciones del menú contextual de una lista, así como su barra de herramientas de toda la aplicación, desde un único sitio.
Constantes. Crearemos las constantes genéricas a utilizar en mensajes, como por ejemplo “Proceso cancelado”, “Debe especificar un nombre”,….

Empezando a organizarnos con v7

Para organizarnos en v7, lo primero que deberíamos hacer, es crearnos una solución con recursos, los cuales utilizaremos para todas nuestras aplicaciones, esta solución debería tener, al menos un proyecto de datos y otro de aplicación. En estos proyectos iremos creando objetos que utilizaremos en cualquier aplicación/solución.

Deberíamos poner en el proyecto de datos todos los objetos que nos permita crear en él, es decir todos los que no requieren interfaz gráfica, y en el de recursos visuales el resto.

Estilo:
Se podría crear un tercer proyecto de aplicación, que llamaríamos estilo, donde incluiremos los objetos visuales que conformen el estilo visual a aplicar, de forma que cuando queramos cambiar el estilo a toda una solución, solo tengamos que cambiar los objetos de esta, o si algún día disponemos de una utilidad de sustituir una caja heredada por otra, mas fácil. Tendríamos múltiples aplicaciones de estilo, y elegiríamos el estilo a aplicar.

Con lo que tendríamos los siguientes proyectos:

Tablas comunes

Recursos

Estilo

Proyecto de datos: Tablas comunes

En este tipo de proyecto, se pueden crear objetos que no utilizan el interfaz gráfico, actualmente son los siguientes:

• Tablas
• Variables
• Tablas estáticas
• Dibujos
• Procesos
• Funciones
• Constantes
• Esquemas

Describimos algunos de estos tipos

Tablas

Crearemos las tablas que según nuestra experiencia siempre utilizamos, sea cual sea nuestra solución o sector. Ejemplos de tablas son; países, provincias, etc..

Variables

Crearemos la lista de variables que siempre utilizamos. Por ejemplo, la fecha en curso, la fecha desde/hasta para las consultas….

Dibujos

Los objetos dibujo se pueden crear tanto en un proyecto de datos como de aplicación, a primera vista puede resultar un poco chocante que algo que es claramente visual, se pueda crear en este tipo de proyectos, pero esto es debido a los objetos esquemas, que veremos a continuación.

Aquí pondremos poner toda nuestra colección de iconos/imágenes, o solo los susceptibles de ser utilizados en proyectos de datos dentro de un esquema, en el proyecto de recursos, podemos tener otros solo utilizables en aplicaciones.

Esquema

Este tipo de objeto que ya existía en v6, ahora tiene una flexibilidad impresionante, y permite que generar no solo una documentación de la estructura de las tablas de uso interno, sino, al poder incluir textos e imágenes crearemos esquemas muy visuales que podremos incluir en la documentación de uso externo.

Como quiera que podemos incluir imágenes en estos esquemas, por eso debemos poner en este proyecto todas las imágenes/iconos susceptibles de ser utilizados aquí.

Recursos visuales

En este proyecto como no va a heredar ningún proyecto de datos, no crearemos objetos del tipo casillero, informe, tubo, etc.

En él crearemos, principalmente:

• Dibujos, los que hemos descartado para el proyecto de datos
• Constantes
• Acciones
• Formularios
• Impresoras lógicas
• Toolbar
• Menús
• Cola

Estilo

En este proyecto de aplicación solo dispondremos las imágenes que utilizaremos para darle un aspecto visual atractivo a los formularios.

También crearemos en este proyecto la paleta de colores que queremos utilizar en la aplicación.

Cuando queramos cambiar el aspecto de toda la aplicación solo tendremos que cambiar este proyecto por otro igual.

Primera aplicación

Una vez creados estos proyectos de recursos, crearemos el primer proyecto de aplicación heredando todos estos proyectos. Este proyecto de aplicación debe ser el que realice el mantenimiento de las tablas del proyecto de datos.

Este será el primer proyecto que contendrá el objeto visual marco, que es lo que en v6 era el AUTOXEC.

Siguiente tema: Proyecto de datos. vBase

v7. Control del acceso a la base de datos

Precedentes

Debido a la ley de protección de datos, a la implantación de controles de calidad y seguridad, cada vez es mayor la necesidad de delimitar dentro de la empresa, quien accede a cada información, y quien puede modificar ciertos datos.

Sobre todo cuando el perfil de la empresa es medio / alto, estos requerimientos de seguridad se tornan exigencias.

Por lo tanto las aplicaciones deben facilitar el establecer múltiples niveles de acceso a la información. Y las bases de datos no pueden permitir que cualquier usuario pueda hacer consultas indiscriminadas de los datos.

Ejemplo

Una ficha de clientes contendrá información con distinto nivel de relevancia:

1. Datos personales. Que podrán ver cualquier persona de la empresa, pero modificar solo, por ejemplo el departamento comercial.
2. Condiciones de venta. Estos datos es muy posible que solo lo puedan ver el departamento comercial, pero solo modificarlo el director comercial.
3. Datos de riesgo. Estos podrían ser vistos por departamento comercial y administrativo, pero solo modificados por este último.

Al igual que este ejemplo se podrían exponer de cualquier información que se maneje (documentos de compra, venta, etc…)

Estos controles se pueden realizar dentro de la aplicación, pero si no se pueden implementar dentro de la propia base de datos, nos encontramos con que toda la seguridad analizada es saltada en el momento que se accede desde fuentes externas, mediante ODBC u otros medios (vDataClient en v7).

Hay que tener en cuenta, que cada vez es mas frecuente el acceder desde estos medios, y además por personal variado, para, por ejemplo, hacer mailings.

Necesidades

Por lo tanto se hace necesario, poder crear perfiles de acceso, tanto a nivel de tablas como de campos, de forma que un usuario a la hora de hacer un “SELECT” de una tabla solo vea los campos a los que tiene acceso, independientemente del medio por el que realiza la consulta.

Y sería bueno que estos controles se puediesen definir desde la propia solución (aplicación), por el usuario, sin tener que hacerlo desde el vServer.

Es decir, que se puedan crear dentro del programa tablas de perfiles de acceso y el usuario asignado como administrador pueda decidir las tablas/campos que puede ver cada usuario.