¿Cómo accedo a la Lista o Ficha de cualquier Vista de datos de mi Aplicación?

Una de las tareas que inicialmente más me costó asimilar fue cómo se podía acceder a los registros de un objeto Vista de datos.

Sigue leyendo para averiguar el porqué.

Cuando uno descubre Velneo, viniendo de un entorno de programación totalmente diferente, debe asumir que va a tener que aprender un nuevo paradigma de programación y esto conlleva algunas dificultades para entender algunos aspectos esenciales del nuevo lenguaje.

vista de datos

 

Como ya sabemos un objeto Vista de datos es un objeto del Proyecto de aplicación que nos permite mostrar en el Interfaz un conjunto de registros de una tabla del Proyecto de datos.

En Velneo se denomina Lista al conjunto de registros y Ficha a un solo registro.

Primero me hice una serie de preguntas en lo que respecta al acceso y gestión de las Listas y Fichas que están contenidas en los objetos gráficos de la Aplicación.

Respondiendo a estas preguntas entenderemos el mecanismo de Velneo y quedará resuelto el problema planteado.

1ª ¿Dónde puedo colocar el objeto Vista de datos en el Interfaz de mi Aplicación?

Los objetos de Vista de datos normalmente irán insertados en un formulario a través de un control de tipo Vista de datos.

También podemos colocar un objeto Vista de datos en un formulario de un Dock del objeto autoexec.

Las Cestas globales también contienen una Lista que podemos mostrar como una Rejilla en un Dock del autoexec.

2ª ¿Desde dónde puedo acceder a la Lista o Ficha de una determinada Vista de datos?

Si no usamos el API, en Velneo solo tenemos acceso a los controles de un formulario desde los manejadores de evento del propio formulario.

Desde un proceso solo tenemos acceso a los controles de objeto autoexec.

3ª ¿Qué comando o comandos me permiten dicho acceso?

En Velneo se entiende por Procesar como la acción de acceder a la Lista o Ficha de la Vista de datos.

Disponemos del comando Interfaz:Procesar que, tal como dice la ayuda, permite acceder a los datos de un control de tipo objeto usado en un formulario o en cualquiera de los subformularios del mismo.

En un control de tipo objeto podremos presentar una ficha o una lista de registros de una tabla.

Mediante este comando podremos acceder a los datos de dicho control e interactuar con ellos, ya sea para leerlos, modificarlos, borrarlos, etc.

En un proceso usaremos este comando para acceder a los objetos Vista de datos de un Dock del autoexec.

Para procesar la Lista de una Cesta global disponemos del comando Cesta:Procesar.

4ª ¿Tiene algo que ver esto con los conceptos de Origen y Destino de los procesos en Velneo?

Por supuesto, si entendemos los conceptos de Origen y Destino, entenderemos porqué necesitamos el comando Procesar.

Cuando ejecutamos el comando Interfaz:Procesar o Cesta:Procesar se crea un nuevo subproceso dentro del manejador de evento o proceso actual. El subproceso cambiará el Origen a la Ficha o la Lista de la Vista de datos que hayamos seleccionado y de esa forma tenemos acceso inmediato.

Cuando finaliza el subproceso, se vuelve a recuperar el Origen que había antes de ejecutar el comando Procesar.

 

Para resumir:

  • En Velneo programamos mediante manejadores de evento y procesos cuyo Origen determina a qué Lista o Ficha tenemos acceso.
  • El comando Procesar crea un nuevo proceso (en realidad es un subproceso) que cambia el Origen a la Lista o Ficha de la Vista de datos.
  • La única condición a tener en cuenta es que la Vista de datos sea accesible desde el manejador de evento o proceso.

 

Una vez entendido cómo funciona el comando Procesar, nos daremos cuenta de la gran potencia de esta forma de programar.

¿Alguna duda en la sala sobre la vista de datos y el comando procesar?

Si es así, cuéntamela dejándome un comentario mas abajo.

La entrada ¿Cómo accedo a la Lista o Ficha de cualquier Vista de datos de mi Aplicación? aparece primero en AyudaVelneo.

Sabías que (2) …

Vamos con una nueva entrega de nuestro mítico juego… “Sabías que“.

Por si te perdiste la primera parte del juego y quieres ganar el primer “quesito” del trivial, aquí te dejo el enlace ¿Sabías que?… Parte 1

¿Sabías que..?

¿Sabías que se puede ocultar la Barra de Estado con un comando nativo de Velneo?

    • Usar el comando Interfaz: Ocultar (STATUS_BAR).
    • Podemos usarlo al inicio de la Aplicación en el evento POS_INI del marco Autoexec.
    • También disponemos de la función del API theMainWindow.hideStatusBar().

¿Sabías que a veces los comandos Else y Else if no funcionan correctamente porque …?

    • Los comandos de instrucción Else y Else if siempre deben estar precedidos de un comando If o Else if. Los comandos If y Else if deben estar situados al mismo nivel y no puede haber ninguna otra línea al mismo nivel entre ambos, ni siquiera un Rem.

¿Sabías que se puede convertir un control de puntero a maestro en un control de edición alfabética?

    • El control de edición del puntero a maestro tiene un comportamiento especial para permitir el Autocompletado o la selección de un registro desde la Vista de datos.
    • Si solo nos interesa mostrar el Nombre del maestro como un control de edición alfabética añadimos el string vacío “” al contenido del campo.
      Por ejemplo el contenido   “” + #PUNTERO_MAESTRO.NAME  hará que las propiedades Autocompletar y Tipo de botones desaparezcan.
      Fijando a 1 el valor de la propiedad Solo lectura conseguimos un control no editable.
    • Recordad que la clase VBoundFieldEdit representa al control de edición de puntero a maestro y la clase VLineEdit al control de edición alfabética.

¿Sabías que se puede determinar el tamaño de los iconos del objeto de lista ListView?

    • El tamaño de los Iconos en un objeto de lista ListView se determina con el tamaño del Dibujo del proyecto que asignamos a la propiedad Icono nulo.
    • Añade al proyecto un objeto Dibujo y ponle un tamaño con el editor (por ejemplo 150x100px) y lo asignas a la propiedad Icono nulo del ListView.

¿Sabes cuándo se calculan por primera vez los valores iniciales de los campos de una Tabla?

    • Desde un formulario se calculan siempre en primer plano.
    • En el plano que corresponda cuando se ejecuta el comando Crear nueva ficha en memoria.
    • La función del API VRegister.setTable() es la que ejecuta los valores iniciales. Tenedlo en cuenta en los bucles que añaden registros a una tabla.
    • Crear Copia de ficha en memoria no ejecuta valores iniciales. Podemos usar el comando Calcula campos dependientes, pero solo funciona con fórmulas que contienen campos de la tabla.
    • Los Tubos de ficha o lista no ejecutan los valores iniciales. Solamente se ejecutan los valores iniciales que dependan de otros campos de la tabla de destino

¿Sabes el orden de las señales cuando se han definido mas de una vez sobre el mismo control?

    • Un objeto de lista del proyecto con una conexión de evento Cambio de seleccionado se incrusta en un control Vista de datos del formulario.
    • En el control Vista de datos definimos la misma conexión de evento Cambio de seleccionado.
    • Se ejecutarán los 2 manejadores de evento, pero siempre primero el manejador de evento del objeto del proyecto.
    • De esta forma podemos tener funcionalidad común en el objeto del proyecto (por ejemplo guardar el ID seleccionado) y en los distintos formularios disparar una conexión de evento con un manejador de evento personalizado cuya primera línea podrá ser

Interfaz: Get variable local de vista de datos (CTR_LISTA, NID_FICHA, NID_FICHA_LISTA)

La variable local de la Vista de datos NID_FICHA tendrá un valor fijado previamente por la conexión de evento del objeto de lista.

¿Sabías que VReport SOLO tiene acceso al proyecto de datos?

    • Desde el editor de fórmulas de VReport solo tenemos acceso a los controles del proyecto de datos de la tabla de entrada (funciones, constantes, variables globales, …)

¿Sabías que un proceso ejecutado desde un formulario recibe como entrada la ficha en memoria que está en Alta o Modificación?

    • El comando Ejecutar proceso ejecutado desde un manejador de evento o desde un botón del formulario pasa como entrada la Ficha que tenemos en memoria en Alta o Modificación.
    • Por lo tanto podemos modificar los campos de la Ficha en memoria sin generar nueva transacción (equivale al comando Pedir formulario).
    • ¡¡Ojo!! no es lo mismo que ejecutar los comandos Crear manejador de objeto, Añadir ficha al objeto y Disparar objeto. En este caso lo que pasamos al proceso es la ficha en disco.

¿Sabías que puedes aplicar formato HTML/CSS a los controles de Texto estático en los formularios?

    • La propiedad Nombre de los controles de tipo Texto estático aceptan código HTML/CSS que se interpreta en tiempo de diseño y en ejecución.
      Un ejemplo de lo que se puede conseguir se muestra en la captura siguiente. Encima de cada Texto estático aparece el contenido de la propiedad Nombre.

VAF_S2_HTML

    • Como se puede ver podemos usar directamente Titulares H1, H2, …, colorear texto, crear líneas horizontales con un simple <hr>, insertar imágenes desde la carpeta caché o directorio por defecto, subíndices y superíndices.
    • No es una funcionalidad documentada, por lo tanto puede desaparecer en futuras versiones.

Y ahora confiesa… ¿cuántas sabías? 

Déjame un comentario mas abajo y comenzamos el debate.

La entrada Sabías que (2) … aparece primero en AyudaVelneo.

Vista de datos: el poder de Velneo al alcance de tus listas

Velneo se define como “Plataforma de desarrollo de aplicaciones empresariales”. Al final el usuario quiere ver datos. Estos datos se muestran a través de listas de registros… y aquí es donde se muestra el poder de nuestro control vista de datos.

Vista de datos listas al alcance de tu mano

En post anteriores vimos como podíamos utilizar el control “vista de datos” para mostrar registros dentro de un menú o cómo optimizar la carga de registros en una vista de datos.

Hoy nos vamos a centrar en el propio control “vista de datos”.

Según la definición de Velneo, la vista de datos es un:

Control de Contenedores que permite incluir dentro de un formulario una acción, desde la que podremos disparar objetos de vista de datos, como por ejemplo, rejilla, formulario, multivista, etc.

 En esta definición aparecen dos de los conceptos fundamentales de Velneo:

  • Concepto de flujo (ya vimos este concepto aquí).
  • Concepto de abstracción o diferenciar el qué del cómo es decir, qué queremos mostrar (lista de registros) de cómo lo queremos mostrar (rejilla, formulario multivista, etc).

Vamos a ver como se aplican estos conceptos.

Crear la vista de datos en nuestro formulario

Hemos visto anteriormente, en la definición de la vista de datos, que éste es un control de los que podemos incluir dentro de un formulario.

Antes de crear los objetos necesarios para mostrar los registros, también deberemos tener en cuenta el flujo. Como ya sabemos, un formulario puede pertenecer a una tabla o ser un formulario sin origen. Por lo tanto deberemos tener en cuenta dónde nos encontramos y qué queremos mostrar.

Generalmente necesitaremos dos objetos para mostrar los registros en nuestra vista de datos:

Control vista de datos

  • En la propiedad “Objeto 1” indicaremos qué queremos mostrar (en este caso los registros que devuelve una búsqueda), por lo tanto una lista de registros: n registros, 1 o ninguno, dependiendo de la búsqueda.
  • En la propiedad “Objeto 2” le indicaremos cómo queremos mostrar esos registros. En este caso al ser la salida del “Objeto 1” una lista de registros, podemos seleccionar cualquier objeto de tipo lista de la tabla a la que hace referencia la búsqueda de dicho objeto.

Esta sería la manera mas sencilla de mostrar los registros de una tabla en una vista de datos… pero Velneo tiene sus peculiaridades.

Consejos antes de crear la vista de datos en nuestro formulario

Algunos consejos antes de crear vistas de datos a lo loco.

  • Si tu aplicación va a ser heredada por otras, nunca vas a saber donde se van a utilizar tus formularios… por lo tanto cuidado con la carga de registros.
  • Velneo carga todos los objetos incluidos en un formulario al crearlo. Es decir si tienes un formulario en el que muestras la ficha de un cliente y en ese formulario tienes un separador de pestañas en el que tienes los plurales de pedidos, albaranes y facturas de dicho cliente… todos esos datos, se cargarán al entrar en la ficha… por lo tanto cuidado con la carga de registros.
  • Si tienes un formulario sin origen que actúa como menú y en dicho formulario cargas n vistas de datos con miles de registros y cada una de ellas se resuelve con una búsqueda de varios componentes, también se cargarán todos los registros al entrar al formulario… por lo tanto cuidado con la carga de registros.
  • Siempre hemos dicho que las búsquedas (o procesos que cargan búsquedas), mejor resolverlas en tercer plano (es decir, en el servidor). Hay una salvedad. Si la búsqueda en cuestión es por un único componente, no vamos a notar diferencia de carga entre lanzarla en primer plano o lanzarla en tercer plano. Para todos los demás casos hay que lanzarlas siempre en el servidor.
  • Siempre que podamos utilizaremos la señal “on-show” del formulario para cargar los registros en la vista de datos mediante un manejador de evento.

Espero que con estos simples consejos no tengáis ningún retardo a la hora de mostrar los registros al usuario.

Utilización del control vista de datos a través de ejemplos prácticos

Particularmente siempre he tenido una “guerra” con los usuarios de mis aplicaciones a la hora de mostrar los registros de un determinado módulo. Están (mal)acostumbrados a que a la hora de entrar, por ejemplo en el módulo de clientes (sirve cualquier otro módulo que se te ocurra) a ver la lista de TODOS los clientes…

  • Si no ven la rejilla con datos… parece que no hay datos.
  • Si al final vas a seleccionar uno en concreto… ¿para que mostrar todos?
  • ¿no será mejor que selecciones primero el rango de los que quieran visualizar?

Como los caminos del Señor son infinitos, vamos a ver varios ejemplos con estas casuísticas.

1.- Mostrar en la vista de datos todos los registros de una tabla al entrar en el formulario que hace de menú.

Lo mas sencillo es hacerlo de la siguiente manera:

Hemos creado un proceso sin origen (ya que el formulario era sin origen) y con destino la lista de la tabla que queremos mostrar en la vista de datos.

Las instrucciones que tenemos en el proceso son:

  • Cargar lista de la tabla por el índice que mas nos interese
  • Añadir lista a la salida (el siguiente objeto en el flujo, recogerá la lista devuelta por el proceso).

Lo único que tendremos que hacer ahora es crear la vista de datos. Como “Objeto 1” pondremos este proceso, y como “Objeto 2” cualquiera de los de tipo lista de la tabla asociada. En este caso “Tareas”

2.- No mostrar en la vista de datos ningún registro de una tabla al entrar en el formulario que hace de menú.

Mi opción preferida… sólo mostramos registros cuando el usuario los seleccione.

En este caso, el proceso no vamos a necesitar igualmente… en el flujo, el “Objeto 2” de la vista de datos tiene que saber que mostrar. La única diferencia es que el proceso asociado no tendrá ninguna línea.

Vista de datos, sin datos

 

Parece increible pero si,  en velneo tenemos procesos que no hacen absolutamente nada… por lo menos aparentemente.

De esta forma, al entrar en el menú no aparecerá ningún registros y será al pulsar sobre un botón cuando se lance la búsqueda que devolverá los registros a la vista de datos.

Tienes el ejemplo completo aquí.

3.- Mostrar en un subformulario de una ficha, un plural (sin optimizar)

En esta caso, ya vamos a estar situados en una ficha, por lo tanto tenemos que tener cuidado con el flujo a la hora de crear los objetos asociados a la vista de datos.

Vista de datos con origen ficha

El montaje es similar a los casos anteriores.

Si recordáis, en uno de los consejos que hemos visto antes os decía que Velneo carga todos los objetos al entrar en este formulario. Por lo tanto los registros que existan en el plural “Desglose de horas” también se cargarán al entrar en la ficha… si tuviésemos 10 plurales mas (sin optimizar) también se cargarían y dependiendo del número de registros que tengamos en cada uno de ellos, es probable que la visualización de la ficha en cuestión se retarde… Y puede además que el usuario sólo quiera ver las “Horas presupuestadas”.

En este caso, lo más sencillo es esto:

Vista de datos de un plural sin optimizar

 

Lo primero es declarar el flujo del proceso, es decir de un origen ficha (de la tabla en la que nos encontremos) queremos mostrar una lista de la tabla destino.

La instrucción para conseguir esto en el proceso es:

  • Cargar el plural que nos interese de la ficha
  • Añadir lista a la salida (invertir lista es para que aparezcan los registros mas recientes al principio de la lista).

Este proceso será el “Objeto 1” de nuestra vista de datos y como “Objeto 2” podremos seleccionar cualquiera de tipo lista del plural en cuestión.

4.- Mostrar en un subformulario de una ficha, un plural (optimizado)

Vamos a realizar algún pequeño cambio para que este montaje esté optimizado y solamente se carguen los plurales al entrar en la pestaña en cuestión.

Vista de datos plural sin datos

 

El flujo del proceso será el mismo… sólo que no le incluiremos ninguna instrucción. De esta forma al entrar en la ficha no se cargará el plural correspondiente.

Ahora tendremos que conseguir que al entrar en la pestaña del plural se carguen en la vista de datos los registros existentes.

Para ello crearemos un “Manejador de evento” en el formulario con las siguientes instrucciones:

Manejador vista de datos

Crearemos una cesta local de la tabla plural que hará de “puente” entre los registros que devuelva el plural y nuestra vista de datos (los registros encontrados se guardarán en dicha cesta).

Con la instrucción “Interfaz: Procesar” accederemos a nuestra vista de datos añadiéndole los registros devueltos por el plural y guardados temporalmente en nuestra cesta con la instrucción “Cesta: Agregar a la lista en curso”.

Sólo nos faltará crear una “Conexión de evento” en el formulario con la señal “On-show” y disparar el manejador que acabamos de crear.

Con este montaje sólo se cargaran los datos de los distintos plurales al acceder a cada una de las pestañas.

 

Espero que a partir de ahora el control vista de datos ya no tenga ningún secreto para ti.

En un próximo artículo veremos todas las instrucciones de proceso que podemos utilizar con este control.

 

¿Alguna duda con respecto al control vista de datos? Si es así, déjame tu pregunta mas abajo en los comentarios.

La entrada Vista de datos: el poder de Velneo al alcance de tus listas aparece primero en AyudaVelneo.

Creación de un menú arbolado paso a paso

Cuando nos acercamos a probar una nueva plataforma de desarrollo, lo primero que queremos es ejecutar algún ejemplo para “ver” como quedaría nuestra aplicación en ese nuevo entorno.

A los desarrolladores que se acercan a Velneo les ocurre lo mismo. Para ello cuentan con el menú arbolado.

menú arbolado

Este planteamiento tiene un problema: quieren “copiar” su aplicación en la nueva plataforma. Idéntica. Mismos menús con las típicas opciones de:

  • Alta de registros
  • Editar registros
  • Eliminar registros
  • Buscar registros
  • Imprimir informes

Os estaréis preguntando el porqué de esta reflexión.

Todo lo anterior viene por este post del foro en el que Carlos dice:

Quiero hacer una app que tiene a la izquierda un dock con opciones arboladas (treeview) al pulsar una rama se contrae o despliega, y al pulsar una hoja ejecuta una acción que abre un formulario. Esta es la base de cualquier sistema pero no me sale. O lo que lei no es -life is soft-. Ejemplo que en access me llevaría 1 hora (ya se que lo domino).

Velneo tiene sus peculiaridades y es verdad que al principio, sobre todo si no has cambiado el “chip”, puede que no descubras todo su potencial… y te des por vencido.

Ya he hablado de ello en “17 errores que te impiden arrancar con Velneo V7“.

En los cursos que he realizado, siempre digo que en Velneo hay que comenzar por el final, es decir por el resultado que queremos obtener:

  • Si quiero lanzar un localizador, primero tendré que tener creada la rejilla a incrustar en dicho localizador y antes el formulario a mostrar al seleccionar un registro. Después crearé el localizador y por último la acción a disparar.
  • Si quiero mostrar un registro desde una búsqueda, primero tendré que crear el formulario de edición de la ficha, después crearé la rejilla (a la que asociaré el formulario creado anteriormente) y por último la búsqueda y la acción.

Pues con las opciones de los menús pasa exactamente lo mismo.

Pasos previos a la creación del menú arbolado

En Velneo lo mas “natural” es tener una única opción de menú para realizar todo el mantenimiento de un módulo… Ya se lo que estaréis pensando “¡sacrílego como es eso posible!”: con el uso de un formulario que “actúa” como menú al que dotamos de toda la funcionalidad que el usuario va a necesitar.

Si no te lo crees te invito a leer antes de continuar “Destripando un formulario menú de vErp” o “Sincronizar vistas de datos en un formulario sin origen“.

¿Ya los has leído?… Pues continuemos.

Con este montaje en el que sólo utilizamos un formulario, logramos simplificar nuestro menú arbolado.

Siguiendo la lógica que te acabo de explicar, el siguiente paso será crear las distintas acciones que vamos a disparar desde nuestro menú.

Montando nuestro menú arbolado

Una vez que hemos montado nuestro formulario que actuará de menú, ha llegado la hora de crear los objetos necesarios para lanzarlo desde el menú arbolado.

Vamos a suponer que queremos montar algo como lo de la siguiente imagen:

Opciones del menú arbolado

Tendremos que crear un árbol de opciones con:

  • Maestros
    • Opciones del menú maestros
  • Oportunidades
    • Tareas
    • Oportunidades
    • Resumen de oportunidades
  • Control de horas
    • Opciones del menú control de horas

Vamos a crear los objetos necesarios para el menú de oportunidades.

Creando las acciones

Necesitamos 3 acciones:

  • TAR_CRM_MEN: lanzará el menú de tareas
  • OPO_CRM_MEN: lanzará el menú de oportunidades
  • RES_OPO_CRM_MEN: lanzará el menú de resumen de oportunidades.

Cada una de las acciones debe quedar como esta de la imagen:

 

Acción oportunidades

Lo importante de la acción son las siguientes propiedades:

  • Comando: en este caso “Disparar objetos”.
  • Objeto 1: objeto a disparar. En este caso el formulario OPO_CRM_MEN que es el que hemos visto en la imagen anterior.

La estructura de las demás acciones será la misma que esta, cambiando las propiedades por los otros módulos a crear.

Por ejemplo la acción de “Tareas” quedaría así:

Acción tareas

Una vez definidas todas las acciones, ha llegado el momento de crear los menús.

Creando los menús

Vamos a crear 4 objetos menú para montar nuestro árbol:

  • MEN_MAE_CRM: para mostrar las opciones de maestros.
  • MEN_OPO_CRM: para mostrar las opciones de oportunidades. En este caso, incluiremos las siguientes acciones:
    • TAR_CRM_MEN
    • OPO_CRM_MEN
    • RES_OPO_CRM_MEN
  • MEN_RES_CRM: para mostrar las opciones de resumen de horas.
  • MEN_GEN: menú que incluirá, en lugar de acciones, los tres menús anteriores.

El menú de oportunidades, quedará como el de la imagen inferior:

Menú oportunidades

Ya tenemos casi construido nuestro “lego”. Nos falta poder visualizar nuestro menú de opciones.

Visualizando el menú arbolado

Como diría un amigo mío, “ya está todo prácticamente a medias”. Tenemos los objetos creados pero todavía no podemos visualizar nuestro menú arbolado.

Para poder hacerlo, vamos a crear un formulario… ¡siiiiiii! vamos a  visualizar nuestro menú arbolado dentro de un formulario.

Menú general vCrm

Si os fijáis en el formulario, la propiedad “Tabla asociada” está vacía… es un formulario sin origen.

Dentro del formulario hemos creado un control de tipo “Menú arbolado” cuyas propiedades son:

Propiedades menú arboladoi

En la propiedad “Estilo“, le indicamos que sólo queremos una rama abierta y que con el simple click, dispara la acción.

En la propiedad “Objeto“, le indicamos el menú que queremos mostrar… en este caso “MEN_GEN”, que es el que incluía los otros tres menús de opciones.

Ya estamos terminando nuestro montaje. Sólo nos falta decidir desde donde vamos a lanzar nuestro formulario “Menú arbolado”.

Modificando el marco “Autoexec”

Para ello, en nuestro marco “Autoexec”, vamos a crear un nuevo subobjeto, en este caso un “Dock”:

Dock menú arbolado

  • En la propiedad “Objeto“, le indicamos el objeto a incluir. En este caso nuestro formulario “MEN_GEN”.
  • En la propiedad “Posición” le indicamos dónde queremos mostrarlo. En este caso a la izquierda.

Y ahora si… por fin podemos ejecutar nuestra aplicación y nos aparecerá un maravilloso menú arbolado a la izquierda de la misma.

¿Has comenzado a cambiar ya el “chip” Déjame tu opinión mas abajo en los comentarios.

La entrada Creación de un menú arbolado paso a paso aparece primero en AyudaVelneo.

Proyectos en Velneo: ¿Cómo estructurarlos?

Cuando comenzamos a desarrollar con la plataforma, una de las primeras cuestiones a resolver es la de cómo estructurar los proyectos en Velneo. Pues como diría un buen gallego: “depende”.

En el post “¿Cuántos proyectos debe tener mi solución?” vimos que lo mas recomendable, es tener un solo proyecto de datos y un solo proyecto de aplicación.

En el post de hoy vamos a ver las ventajas y los inconvenientes de distintas formas de estructurar los proyectos en Velneo.

Estructurar los proyectos en Velneo

 

Tipos de estructura de proyectos en Velneo

Para saber la estructura que tienen que tener los proyectos, y por consiguiente nuestras soluciones, tendremos que responder a una serie de preguntas. Entre ellas podemos destacar las siguientes:

  • ¿Mi aplicación va a ser heredada por otras soluciones?
  • ¿Quiero facilitarle la vida a otros desarrolladores?
  • ¿Cómo voy a distribuir mi solución? ¿Como un todo?, ¿Por módulos?
  • ¿Quiero que mi solución sea la base de otras soluciones?
  • ¿Quiero tener distintas instancias por módulo. o una instancia para todos los módulos?

En función de lo que contestemos, tendremos que estructurar nuestros proyectos.

Proyectos “Monolíticos”

Son aquellas soluciones que tienen un proyecto de datos y un proyecto de aplicación. Un ejemplo de esta estructura de proyectos en Velneo es mi aplicación GTDenlanube.

Proyectos en velneo: Estructura monolítica

Estructura monolítica

Ideal cuando empezamos a desarrollar con Velneo V7. Evitamos complejidad.

Nos despreocupamos de crear tablas de extensión y herencia inversa.

Facilitan la herencia a otros desarrolladores.

No se puede trocear.

Dificulta el desarrollo colaborativo.

No es escalable al estar todos los módulos en el mismo proyecto.

Todo el peso está en la misma solución, con altos consumos de memoria a medida que añadimos funcionalidades. Si tuviesemos un ERP + CRM + TPV + CONTABILIDAD, tendríamos en una solo instancia todos los objetos... ahora imaginad mas módulos: cartera, producción, etc etc.

 

Proyectos “Verticales”

Son aquellas soluciones que tienen un proyecto de datos y varios de aplicación. Un ejemplo muy claro lo tenemos el vErp

Proyectos en Velneo: Verticales

Ya tenemos dos proyectos de aplicación perfectamente diferenciados: vTPV y vERP. Por lo tanto podemos instanciar por separado... aunque los datos siguen estando en la misma instancia.

Facilitan a los desarrolladores las personalizaciones sencillas

Los datos siguen estando en el mismo proyecto.

No es escalable

Proyectos “Horizontales”

Son aquellas soluciones que tienen varias soluciones independientes relacionadas por un proyecto que las hereda. Un ejemplo muy claro lo tenemos en los módulos de la plataforma PaaSOS de Tipesoft. Los módulos de PaaSOS tienen un único proyecto de datos y uno de aplicación…. heredando de un núcleo común (veremos este montaje “mixto” a continuación).

Proyectos en Velneo: Horizontales

Módulos completamente independientes.

Perfectamente escalables.

Peso de las soluciones repartido evitando consumos de memoria desmedidos.

Facilita la extensión de nuestras soluciones.

Facilita el desarrollo colaborativo.

Complejidad en la visibilidad de los datos. Unos módulos no tienen "conocimiento" de los datos de su solución hermana.

Imposible la herencia entre soluciones "hermanas". Si es posible mediante la API de Velneo.

Si queremos utilizar varias soluciones, tendremos que "empaquetarlas" en distintos packs.

Proyectos “Mixtos”

Son aquellas soluciones, generalmente de tipo Monolítico que heredan otras soluciones (del tipo que sean). Son aquellas soluciones que creamos para no tocar o ampliar la solución base y poder beneficiarnos de futuras actualizaciones de dicha solución: soluciones que creamos heredando vERP, soluciones que creamos heredando el núcleo de PaaSOS

Proyectos en velneo: Mixtos

Facilitan la instalación de nuevas versiones de nuestra solución base.

Perfectamente escalables.

Facilitan la extensión de la solución.

Facilitan el desarrollo colaborativo.

Complejidad en la herencia de soluciones.

No están recomendados para usuarios que comienzan con la plataforma. Necesitan conocimiento de estructuras avanzadas en Velneo V7.

 

¿Ves alguna ventaja o inconveniente mas en la forma de estructurar nuestros proyectos en Velneo?

Coméntame tu experiencia mas abajo.

La entrada Proyectos en Velneo: ¿Cómo estructurarlos? aparece primero en AyudaVelneo.

Cómo mostrar la suma acumulada de los registros seleccionados en el pie de la rejilla

Los que venimos de 6x echamos de menos una instrucción muy útil que había en los pies de las rejillas: “Suma acumulada de los marcados”. Con esta instrucción conseguías que apareciese la suma acumulada de los registros seleccionados por el usuario en en el pie...

La entrada Cómo mostrar la suma acumulada de los registros seleccionados en el pie de la rejilla aparece primero en AyudaVelneo.

Destripando un formulario menú de vErp

En vErp (y en casi todas las aplicaciones desarrolladas con Velneo V7) las opciones de un modulo (familias, artículos, albaranes, etc) están integradas dentro de un formulario sin origen que actúa a modo de menú. Desde esté menú se realizan todas las operaciones relacionadas con los datos de la tabla (dar altas, editar un registro, localizar, buscar, etc). ¿Quieres aprender a desarrollar un formulario de este tipo?… Pues sigue leyendo Construyendo el menú He cogido como ejemplo el menú de “Formas de pago” de vErp: Como diría Jack “destriparemos el menú de vErp por partes” Vamos a comenzar detallando los distintos objetos que aparecen en el formulario: Control de edición alfabética NOM_BUS_1: Lo primero que nos encontramos es un control de edición para que el usuario introduzca la palabra por la que va a querer buscar los registros… después veremos como se lanza esa búsqueda. El contenido de este control es una variable local al formulario llamada NOM. Estará visible si no se ha disparado la búsqueda avanzada. Botón “Buscar”: Este botón llamado “BTN_BUS_1″ lanza el manejador de evento BUS (lo veremos en detalle después). Este botón es el que ejecuta la búsqueda de registros en la tabla [...]

El artículo Destripando un formulario menú de vErp fue publicado en Ayudavelneo por Francisco José Vila Martín