Profundizando en vBase

Hemos estado profundizando en la estructura que debe tener el módulo vBase, para ser lo mas generalista posible y pueda ser utilizado para cualquier propósito. Como consideramos, al igual que otros desarroladores de v7, que este módulo deberiamos homologarlo lo mas posible, he procedido a contrastar mi planteamiento con otras personas con experiencia. Este es el caso de Hector Santoveña y Jorge Velasco. Nuestra intención es homologar los proyectos de datos, dejando los de aplicación para que cada uno aplique el estilo que desee. Una vez terminada la definición de campos publicaremos el proyecto para que pueda ser descargado por la comunidad.
Después de nuestras conversaciones, dividimos las tablas de la siguiente manera:

• Universales. Tablas de uso universal, que podrían ser compartidas, por aplicaciones diferentes e incluso por clientes diferentes. Estas podrían estar en un proyecto separado, y compartido. Dentro de este apartado tenemos:
  • Divisas
  • Cambios de divisas
  • Idiomas
  • Paises. Dentro de los paises hemos desglosado hasta 2 divisiones
    • División 1 (comunidades autónomas)
    • División 2 (provincias)
  • Tipos de vías
  • Localizaciones: Códigos postales, localidades y calles. Esta es una tabla que nos permite obtener el código postal de una localidad o una calle indistintamente
  • Bancos, sucursales bancarias
• Entidades y contactos. En este apartado disponemos de la tabla de entidades y todas sus relacionadas
  • Tablas maestras
    • Categorías
    • Tipos de relación
    • Clasificaciones. Para ser utilizada por el usuario final para cualquier fin.
  • Entidades
    • Entidades
    • Contactos. Relación de personas de contacto de una entidad
    • Direcciones. Direcciones postales
    • Relación entre entidades. Tabla de relaciones entre entidades
    • Categorías de una entidad
    • Centros o subdivisiones de entidad. Esta es una tabla de propósito múltiple, será utilizada para dividir la entidad en subentidades de control. Ejemplos: Centros de trabajo o de logística, Proyectos, centros de coste. Por ejemplo desde una gestión podría ser el almacén origen o destino de la mercancía.
• Empresa
  • Empresas
  • Usuario por empresa
  • Entidades por empresa
• Usuarios de la aplicación. Estas tablas las tenemos en un proyecto diferente, que es heredado por este.
  • Usuarios
  • Grupos de usuarios
  • Usuarios por grupo

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:

Módulos básicos

Con la experiencia adquirida hasta el momento, y con las nuevas funcionalidades de la 7.2, hemos organizado una serie de soluciones, que serán a partir de las que se crearán el resto.

Datos comunes

Consideramos que toda aplicación debe tener una gestión de usuarios, y sin embargo no tiene por que tener una gestión de entidades / contactos. Por lo tanto hemos decidido separar en una solución diferente la gestión de usuarios.

En esta solución incorporamos las variables globales que utilizamos habitualmente. Proyectos:

• Datos comunes. Proyecto de datos, con las tablas de usuarios / grupos de usuarios, y las variables de uso general
• Recursos. Proyecto de aplicación, donde tendremos el mantenimiento de las tablas de usuarios, y los recursos/utilidades generales (Iconografía, funciones standard,….)

---

Hojas de estilo

Ya que actualmente podemos separar totalmente el código del aspecto visual de la aplicación, y permitir que cada usuario tenga personalizado su estilo visual (gracias al comando set hoja de estilo), hemos creado una aplicación específica para diseñar hojas de estilo.

Esta aplicación consta de:

• Hojas de estilo.Dat. Proyecto de datos, donde estarán los estilos creados, y que podrá ser heredado por cualquier solución. Dispone de una función a la que se le pasa como parametro el código de la hoja de estilo a utilizar, y te lo devuelve. Si se pasa un cero, devuelve la última que a utilizado el usuario desde el ordenador en el que está.
• Hojas de estilo. Proyecto de aplicación, desde donde el diseñador creará las distintas hojas de estilo. Este proyecto no será heredado por ningún otro.

Almacén de objetos en v7

Los que venimos de velneo v6, sabemos lo que es el almacén de objetos y la metamorfosis al vuelo. Y nuestra pregunta es ¿Cómo puedo tener un almacén de objetos en v7?.

Precedentes

En v6, solía venir con la instalación de la herramienta un pequeño almacén de objetos. En esencia eran pequeños mapas (proyectos). Existían dos tipos:

1. Programas sencillos con una funcionalidad, que por un lado te servían de ejemplo a los no iniciados, y por otro podías incorporarlos a tus desarrollos.
2. Objetos visuales de una tabla tipo (VMAESTRO). Eran mapas (proyectos) que tenías todos los objetos visuales de una tabla, con un estilo concreto.

Mas tarde salieron las plantillas empresariales (vBase, vGestion,….). Este código abierto además de ayudar a aprender la programación en Velneo, a un nivel más avanzado que los programas que venían de serie con la herramienta, permitía partir de un código elaborado para crear aplicaciones.

Con estas aparecieron los complementos (vMail, vODBC,….). Código reutilzable en diversas soluciones.

Una vez que ya caminabas solo, y eras capaz de hacer tus propias aplicaciones. Por un lado utilizabas los complementos que te pudiesen interesar, y muchos eran interesantes, para incluirlos en tus aplicaciones. Pero sobre todo utilizabas el almacén de objetos para el desarrollo rápido de aplicaciones, aprovechando la metamorfosis al vuelo. Quien mas quien menos tenía sus módulos en el almacén, de lo cuales tiraba para crear nuevas tablas o nuevos objetos de tablas existentes.

La actualidad

En la v7 existen las Open Apps . Estas permiten cubrir por un lado el aprendizaje, y por otro (gracias a la herencia) la disposición de complementos reutilizables, con la gran diferencia de que el código está siempre separado; por lo que puedes veneficiarte de nuevas versiones sin tener que tocar nada de tu código, con solo actualizar el complemento lo tendrás operativo en todas las soluciones que lo use. Esto es una gran ventaja de la v7.

Seminario Juan Muñoz Cobos

El viernes tuvimos la oportunidad de ver de nuevo a Juan en acción, explicandonos el pasado, presente y futuro de la v7.

Escuchamos de la voz mas autorizada, el porqué de la v7, cuales son sus objetivos, cual es el estado actual, como se llegó hasta aquí, y también parte de lo que nos espera.

Nos contestó, públicamente, a nuestra duda sobre las rejillas, se ha decidio por la opción 6 (buscar una rejilla de otros desarrolladores), lo cual bajo mi opinión es un acierto, y eso ha llevado tiempo (lo cual no me extraña, por lo exigente del examinador ), parece que ya ha encontrado lo que busca y seguro no nos defraudará. Como siempre aunque la espera sea larga, habrá merecido la pena.

Ha sido muy grato escuchar la gran apuesta por los estandares, lo que hará mucho mas fuerte a la herramienta. Otro gran acierto de esta nueva era.

En un momento de la intervención, comentó el debate interno en Velneo, entre la conveniencia o no de contar en que están trabajando, los planes de futuro, que podemos esperar a medio y largo plazo de la v7. Parece que existen dudas sobre lo mas conveniente.

Yo entiendo perfectamente que tengan dudas, por la experiencia pasada. Creo que al principio, cuando la criatura aún era un embrión, el hablar demasiado de lo que iba a ser, fué, a veces, contraproducente, pero sobre todo por que las espectativas venían con unos plazos que no se cumplieron.

Pero ahora ellos ya saben, y nosotros ya lo empezamos a ver, que el niño ya a pasado esos momentos dificiles, y ya sabe caminar. La 7.2 es la prueba y las siguientes versiones deben ser la confirmación.

En estos meses, si hubo un arduo debate de si se empezaba o no a desarrollar con la v7, por que nos faltaba tal o cual componente, siempre comparando con la v6. Pero con la versión en el estado actual, las diferencias con la v6 están en detalles, que pueden ser muy importantes o no, pero que se deben pulir en la siguiente versión. Y ahora no creo que nadie, dejase de empezar con la v7 hasta que tenga alguna de las cosas que pueda tener en el futuro.

Yo personalmente, me gusta saber lo que tengo, lo que tendré a corto plazo, y lo que puedo esperar a medio y largo.

Para mi, de lo mejor de la jornada, fueron las pinceladas que dió sobre las cosas en las que estaba trabajando, lástima que no se extendiera mas. Pero el saber que estaban, por ejemplo, trabajando en poder disponer de un visor de tablas SQL, o en integrar  nuestra base de datos con tablas de bases de datos externas. No solo no me hizo pensar en esperar para empezar con la v7, si no que me cargó las pilas, para seguir.

Por que cuanto mas grande sea la empresa en la que puedes entrar, mas posibilidades tienes de encontrarte con bases de datos con las que tendrás que convivir. Y tenemos que poder integrarnos con Navision, Oracle, o cualquier base de datos de la competencia.

En terminos generales, y por lo comentado con los asistentes, el seminario no defraudó a nadie.

Al final tuvimos la oportunidad de compartir una vComida con algunos de los asistentes, lo que redondeo una gran jornada.

v7.2 Rejilla. La gran olvidada

Ya tenemos la v7.2, y realmente trae muchos objetos y funcionalidades nuevas, muy interesantes. Muchas de ellas son funcionalidades que se tenían en v6, y ahora ya están en esta versión y en algunos casos mejoradas.

En otros casos como las hojas de estilo, las imágenes y controles SVG, novedades que aportarán a nuestras aplicaciones plasticidad, y amigabilidad.

Ha sido un gran esfuerzo, y necesario, esta versión ya se puede considerar una buena versión de trabajo…… pero…..

A veces tengo la impresión que nos centramos mas en lo espectacular que en lo funcional, tenemos muchos objetos nuevos que nos permitirán hacer aplicaciones mucho mas ricas. Sin embargo, toda aplicación de gestión (y la v6 al menos era una herramienta orientada a desarrollo de aplicaciones de gestión), tiene un objeto principal, por el que siempre se pasa para llegar a cualquier sitio, y ese no es otro que la rejilla, por eso no entiendo que salgan versiones y sigamos con una rejilla que solo hace lo mas básico, y no llega ni tan siquiera a lo que hacía la rejilla de la v6; cuando, esta última, era una de las piezas que mas mejoras necesitaba.

No entiendo por que en el vDataClient la rejilla es editable, y sin embargo en desarrollo no. ¿?

Una base de datos, es en esencia un montón de datos organizados en cajas (tablas) llenas de fichas (registros), y que el usuario debe poder manejar de una forma ágil y cómoda. Debe poder, de una vista rápida ver múltiples fichas y saber cuales son las más destacadas según distintos criterios, y para esto no se me ocurre mejor manera que una rejilla. Debe poder editar múltiples registros de forma rápida. Y como estos muchísimos ejemplos.

La mayoría de los programadores de v6, deseabamos algún día tener una rejilla que diese juego, nos permitiese tener distintos niveles de agrupamiento, columnas personalizables por el usuario (dentro de las que le permitamos por programación), edición real……

Me gustaría saber, cual es el motivo para que este objeto, apenas tenga mejoras. A mi se me ocurren varios:

1. El objeto se considera que tiene suficiente.
2. El objeto no da mas de si y hay que conformarse.
3. El objeto se va a mejorar, pero no es prioritario. No se le da suficiente importancia, y nos centramos en otros que son novedosos y espectaculares.
4. El objeto no da mas de sí y se está buscando otro, pero sin prisa.
5. El objeto no da mas de sí y se está trabajando en otro intensamente, pero aún no está terminado.
6. El objeto no da mas de sí, es algo prioritari y se va a cambiar por uno de otros desarrolladores, pero aún no se ha decidido cual es el adecuado.

Me gustaría que Velneo, nos dijese que pasa con este objeto. Yo creo (o quiero creer), que es uno de los 2 últimos puntos, y lamento no tengamos nada mejor en esta versión, y confío que realmente lo tengan como algo prioritario, y en la próxima versión, sin falta, tengamos un objeto rejilla acorde con la v7. Pues ahora es el patito feo, cuando debería ser el cisne que presidiese el desfile.

v7.2. Primera impresión

Por fin tenemos la versión 7.2 de nuestra herramienta, y como siempre viene con muchas novedades, ahora es tiempo de analizar y valorar lo que nos aportan y … lo que seguimos echando en falta. Pues esto no acaba aquí y seguro que aún nos faltarán cosas que teníamos con la v6.

Hoy vamos a comentar sobre las novedades estrella (esas que nos ponen en los titulares para dejarnos boquiabiertos), luego habrá que entrar en los objetos que no forman parte de titulares, y pueden ser mas importantes para el día a día de los mortales.

Objeto fichero adjunto al proyecto

Objeto que no teníamos en la v6, y que nos permite incorporar a la aplicación cualquier fichero y distribuirlo de forma automática al cliente. Estos ficheros pueden ser de múltiples propósitos, pero la finalidad inicial es la de distribuir las DLL, nuevo y esperado objeto de esta versión.
Su funcionamiento es muy sencillo, simplemente se dice el nombre del fichero, y los sistemas operativos para los que sirve. El programa se encargará de tener actualizado el cliente con la última versión de nuestro fichero. Para ello se utiliza un directorio caché. También aparece una nueva variable de sistema “sysCacheClientPath” que nos permitirá utilizar ese directorio desde el programa

Objeto librería externa

Este si era un objeto muy demandado por la comunidad, y que por fin aparece, con la flexibilidad de poder tener librería para cualquier plataforma.
Con este objeto se abre un campo amplio de posibilidades, pero sobre todo nos permite recuperar todos los proyectos que teníamos con v6 que utilizaban librerías.
Una de las ventajas de estos dos objetos es que una vez programados nos podemos despreocupar del cliente, pues siempre estará con la última versión, ya que al conectarse, el sistema verificará si tiene que actualizarse o no.
Otra es que, ya junto con esta versión, aparecen open apps que utilizan la “viejas librerías” de la v6 v2Excell, vMail…

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:

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.

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.