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:

Sigue leyendo

Anuncios

Almacén de objetos. Maestro búsqueda avanzada

Vamos a realizar una búsqueda avanzada. Nuestro objetivo es que desde una sola búsqueda podamos buscar por:

  1. Código. Un registro por su código (ID)
  2. Trozos. Todos los registros que contengan en cualquier parte del nombre los trozos de palabra escrita
  3. Palabras. Todos los registros que contengan en cualquier parte del nombre todas o alguna de las palabras escrita
    • Todas
    • Alguna
  4. Alfabético. Todos los registros que empiecen por el texto dado
  5. Fecha de modificación. Todos los registros modificados entre las fechas indicadas.

Para ello lo primero que necesitamos son unas variables para indicar el tipo de búsqueda elegida. Estas variables las crearemos en el proyecto de datos, y nos servirán para las búsquedas en cualquier tabla.

BUS_TROZOS_PAL_ALFA.- Numérica. Nos indicará, si el texto introducido lo usamos para buscar por trozos (valor 0), palabras (valor 1), o alfabético (valor 2)

BUS_PAL_ALGUNA.- Booleana. Nos indicará si tiene el valor 1 que queremos alguna de las palabras y en caso contrario (valor 0) serán todas las palabras.

INTERVALO_FECHAS_MAEST.- Será una variable booleana que nos indicará que queremos acotar por fechas

BUS_FCH_DESDE.- De fecha. Será la fecha desde la que queremos acotar

BUS_FCH_HASTA.- De fecha. Será la fecha hasta la que queremos acotar

Una vez creadas pasaremos a crear el formulario para la búsqueda.

El formulario será un formulario con layout vertical. Vamos a crearlo utilizando un estilo, utilizando los objetos del proyecto de aplicación estilos. Entonces definiremos las siguientes propiedades del formulario:

Dibujo de fondo FORM_BGR

Aspecto del dibujo estirar/encoger

Margen izquierdo 0

Margen derecho 0

Margen superior 0

Margen inferior 0

Dentro del formulario crearemos 4 layout, 2 de tipo horizontal y 2 de tipo grid, que describimos a continuación.
Sigue leyendo

Almacén de objetos: Maestro código numérico

Vamos a describir lo que sería un mantenimiento de una tabla básica, lo que en la v6 se usaría dentro del almacén de objetos.

Tendremos un proyecto de datos y otro de aplicación, con una sola tabla MAESTRO.

Proyecto de datos

Los campos que contendrá esta tabla serán:

todos su índices, salvo CODIGO, están condicionados a que el valor del campo DEL sea 0, salvo el índice BAJA, que lógicamente estará condicionado a que el valor del campo DEL sea 1.

Proyecto de aplicación

El proyecto de aplicación lo empezaremos creando el formulario de mantenimiento. Para ello pulsamos el botón de formulario, y utilizaremos el
asistente de formularios.

Una vez creado el formulario con sus botones por defecto vamos a personalizarlo.
Sigue leyendo

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”,….

Proyecto de datos común. vBase

Antecedentes

Vamos a desarrollar lo que será el proyecto de datos del que deberían partir todos nuestros proyectos. Los programadores que ya llevan un tiempo con Velneo, ya conocen sus plantillas, y saben que la primera y de la que parten todas es la
vBase. Así mismo sabrán que en el momento que empezabas a desarrollar o personalizar módulos, acababas modificando esa plantilla, y cuando aparecían nuevas plantillas, cada vez resultaba mas difícil, incluso imposible, integrarlas con tus desarrollos. Por otra parte si tu desarrollo no era una gestión o un entorno con clientes/proveedores, entonces o desarrollabas algo totalmente distinto, o “destrozabas” la vBase para aprovechar lo poco que te podía servir.

Con la v7 podremos encapsular los proyectos, de forma que puedan ser utilizados por otros, sin tener que realizar ninguna integración. Esto nos podría servir para que una empresa que tenga un CRM, lo pueda integrar con otra que tenga una facturación, sin complejos procesos. Claro que para ello tiene que haber una filosofía y un nexo común. Este nexo común, entiendo que debe ser este proyecto de datos “vBase”.

Por otra parte será muy importante que cada módulo que desarrollemos lo pensemos cerrado, en el sentido que su estructura interna no sea afectada por la integración con otros módulos. Tenga, como los objetos de v7, una/s entrada/s y una/s salida/s y el resto sea interno, y cuando exista una nueva versión, si esos puntos de entrada/salida no cambian, con solo sustituir una versión por otra estará todo operativo.

Partiendo de estos precedentes, aquí voy a explicar mi visión de lo que debería ser una vBase, de forma que pueda servir tanto para desarrollar un ERP o para hacer una aplicación para academia, donde en lugar de clientes tiene alumnos, y en lugar de proveedores tiene profesores.

Bien como decía en el artículo anterior, este proyecto de datos deberá contener las tablas que usaremos siempre en nuestras aplicaciones, y en cualquiera de ellas lo habitual es que interactuaremos con personas o empresas, y que necesitemos guardar sus datos personales (nombre, teléfono,…). Por lo tanto este proyecto girará alrededor de una tabla que llamaremos entidades.

Primeras tablas

Partiremos de la Open Apps de Velneo: http://velneo.es/71756/vbase/

Localización. En cualquier aplicación es habitual tener una tabla de provincias y/o países, que no permita ubicar a nuestros contactos. En algunos casos seguro que muchos habremos necesitado crear una tabla de comunidades autónomas, códigos postales o poblaciones.

Por lo tanto se deben crear varias tablas que no permitan, de forma flexible determinar el grado de detalle para definir una ubicación. Aquí no me voy a detener mas, y os remito a la estructura que han montado en Velneo para resolverlo.

Esquema de localización

Esquema de localización

Empresa que usa la aplicación.También es habitual tener una tabla donde guardemos los datos de la empresa o empresas que usan la aplicación. En algunos casos habremos creado solo unas variables de disco para guardar el nombre de la empresa, en otros seguro creamos una tabla con un registro donde guardábamos esos datos, y cuando necesitamos que nuestra aplicación fuera multiempresa, pues hemos usado esta tabla para crear todas las empresas necesarias.

Usuarios. También podemos tener una tabla de usuarios de la aplicación. En este caso podemos usar una tabla exclusiva para guardar su nombre o integrarlos en la tabla de entidades, donde ya podremos tener todos los datos personales habituales, y eso es lo que haremos.

Entidades. Esta es la tabla donde estarán todos nuestros contactos, sean empresas o personas físicas. Lo que yo entiendo es que debería ser una tabla como es la de contactos de cualquier programa de oficina o correo electrónico. Compatible con nuestros contactos de móvil, o de la agenda electrónica.

Profundizando Sigue leyendo

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.

estiloObjetos
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.

ProyectoBase
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.