BLOG

Ámbito de las variables

Por [N4] rcueto.velneo el | 9 Comments

En Velneo V7 existen dos objetos que nos permiten almacenar datos individuales, las varibles globales y las variables locales.

En este artículo os explicaré tanto la diferencia entre ellas como su ámbito de ejecución.

La varible global es un objeto cuyo contenido es global a la aplicación y común, en el ámbito de red, para todos los usuarios si su persistencia es en disco, y de carácter local si su persistencia es en memoria.

La variable local es un subobjeto definible dentro de un objeto. Se trata de una variable local al objeto en el que ha sido declarada, y solamente será accesible desde ese objeto o desde otros sub-objetos del mismo. La persistencia de este tipo de variables es en memoria.

Ámbito de las variables globales

El contenido de una variable global en disco es común a todos los usuarios y planos de ejecución (tanto en los clientes como en el servidor).

Por tanto, si desde una sesión de Velneo vClient V7 se modifica una variable global en disco, esta modificación afectará tanto al resto de los clientes que estén ejecutando la misma instancia como a los procesos que hagan uso de ella en el servidor (procesos ejecutados en tercer plano).

Debemos tener en cuenta que cada vez que se usa una variable global en disco, Velneo vClient V7 debe solicitarle al servidor el valor de dicha variable, por si ha cambiado, lo que supone una conexión a través del enganche correspondiente y, por lo tanto, mayor tiempo de ejecución que si utilizamos otras técnicas. En muchos casos leer el valor de una variable global en disco no supondrá ningún problema, sin embargo, debemos evitar usar variables globales en disco en contenidos iniciales o fórmulas de campos que se calculen en todos los registros ya que eso puede producir sensación de lentitud en nuestras aplicaciones.

Si por ejemplo usamos una variable global en disco en un campo de tipo fórmula y en una rejilla en la que se muestra ese campo cargamos una lista de registos, dado que el contenido de este tipo de campos se calcula dinámicamente, por cada registro a presentar en la lista se deberá leer el valor de la variable global en el servidor para calcular la fórmula, lo que provocará una ralentización en su carga.

El funcionamiento de las variables globales con persistencia en memoria se circunscribe al ámbito estándar de funcionalidad de este tipo de variables en los lenguajes de programación genéricos que, básicamente, consiste en ser globales a la máquina en la que se haga uso de ellas. No hay replicación entre clientes y servidor y viceversa.

Es decir, que la modificación que haga un usuario a una variable global en memoria afectará única y exclusivamente a esa sesión de Velneo vClient V7. No afecta a otras sesiones de vClient (ni abiertas en la misma máquina ni en máquinas diferentes) ni al servidor.

Por ejemplo, si modificamos una variable global en memoria en un proceso ejecutado en primer plano y lanzamos desde éste un proceso en tercer plano (ejecución en el servidor) que use esa misma variable global, no se replica el valor dado en esa sesión de vClient, sino que tomará el valor que tenga en el servidor.

Si modificamos una variable global en memoria en un proceso ejecutado en 2º plano, y ejecutamos al mismo tiempo otros proceso en 2º plano que hagan uso de la misma, el cambio afectará a todos ellos.

Ámbito de las variables locales

La norma general es que las variables locales son locales al objeto donde se definen y solamente están accesibles desde éste, aunque existan otros objetos que tengan declarados variables locales idénticas.

En un formulario podemos declarar una variable local y ésta será común al formulario y a todos los subobjetos del mismo.

Por ejemplo, podremos usar una variable local definida en el formulario en un evento de intefaz del mismo.

En un formulario podemos usar controles que agrupan o contienen otros objetos. Por ejemplo, podemos incrustar una rejilla mediante el uso de un control llamado control objeto. Debemos tener en cuenta que en este caso la rejilla no es un subobjeto de formulario (el subobjeto es el control objeto que la contiene), por tanto, no hay compartición de varibles locales entre ambos (formulario y rejilla), aunque se llamen de igual forma.

De igual modo un formulario no es un subobjeto de una tabla, por lo tanto, las variables locales definidas en ambos objetos son locales a cada uno de ellos y no hay, por tanto, interacción entre ambos.

Por último, mencionar que en Velneo V7 las variables locales ganan peso y funcionalidad frente a las variables globales; de ahí la existencia, por ejemplo, de los comandos de proceso de objetos que nos permiten, desde procesos o eventos de interfaz, gestionar las variables locales de otros objetos, y el traspaso automático de variables locales de formularios de búsqueda a las búsquedas. Podrás ampliar información al respecto al final del capítulo dedicado a las búsquedas.

Velneo es el entorno ágil para el desarrollo
de aplicaciones empresariales

PRUEBA VELNEO

9 Responses to "Ámbito de las variables"
  1. [N4] eic.eurosistemas dice:

    Hola.
    “No hay replicación entre clientes y servidor y viceversa”.
    ¿Es ése el funcionamiento establecido por diseño? He vuelto a mirar en vBugman, pues había una incidencia sobre la replicación de variables globales en memoria, y veo que es una “Sugerencia”. Pero si el valor de una variable global en memoria “en el servidor” es “global para todo el servidor”, de poco va a servir que se repliquen los valores, pues afectarían a todos los usuarios, y no sólo a los procesos en el servidor lanzados por una sesión particular de un cliente.
    En muchos casos, utilizo variables globales en memoria para almacenar parámetros del usuario que accede a una sesión concreta. Y a veces, hay que utilizar esas variables en procesos en el servidor (para agilizar el rendimiento), pero si su valor en el servidor es global, habrá que plantearse otros métodos. 
    Es una pena que se haya perdido el concepto de “variable global en memoria independiente para cada tarea en 2º plano”, que había en 6.x.
    Saludos,
    Fran Varona
     

  2. Pepeto dice:

    Si lo que deseamos/deseais es potenciar el uso de Variables Locales en vez de globales, se deberia habilitar de alguna forma el paso de valores entre variables locales de un objeto a otro
    p.e. Si estoy en un formulario que incluye un control objeto, dentro del control objeto puedo incluir rejillas, otro formulario, etc y no hay una forma facil de compartir estas variables,
    Mientras esto no se solucione, las variables globales, seguiran siendo necesarias.
    Hay otra forma de solucionar los problemas, pero es, quiza demasiado laborioso si pensamos en lo sencillo que deberia ser algo tan basico.
    un saludo
    José

  3. Estoy totalmente de acuerdo con Fran.
    Saludos
    OVerall

  4. Juan Figueroa dice:

    Ya para la V 5.x y V6.x había pedido yo que los objetos, en especial los procesos, las búsquedas y los tubos, admitieran el pase de parámetros, al menos cuando son llamados desde un proceso, esto ahorraría el uso de variables globales, tan visibles y por tanto tan potencialmente peligrosas por colisión, evitando también la proliferación excesiva de estas variables con la consecuente necesidad de creatividad para nombrarlas y luego reconocer estos nombres (sobre todo con selectores tan parcos en tamaño). Luego a parecieron las funciones y los componentes HTML que admitían el pase de parámetros – ¡Qué alegría! pero no cundió el ejemplo. ¿Os imagináis lo que nos ahorraríamos en procesos casi idénticos si admitieran parámetros de entrada desde otro proceso y lo encapsulado que quedaría todo? De cine.
    No sé si con las variables locales a los objetos en V7 podemos tener todo esto.
    También en V&.x, la variables globales en disco se replicaban interna y automáticamente en variables globales en memoria con el mismo nombre y eran de acceso más rápido. En V7 ¿cómo es?
     

  5. [N4] jorge.hontoria.tipesoft dice:

    Por un lado las nuevas formas de manejo de objetos en v7 permiten la programación avanzada mediante variables locales. Con este nuevo escenario v7 parece ser infinitamente más versátil que v6. Pero la realidad vuelve a ser tozuda. http://tipesoft.com/el-infierno-y-ii-de-las-variables-locales-en-velneo-v7/http://tipesoft.com/paasos-soluciones-a-problemas-cotidianos/
     
    Por otro, totalmente de acuerdo con Fran. Los ámbitos de las variables globales en v7 son poco versátiles, me explico:
    EN DISCO: Las variables en disco son compartidas entre todos los clientes/sesiones de la instancia (cuestiones de rendimiento a valorar).
    EN MEMORIA: Las variable globales en memoria son compartidas dentro de la sesión en la que se haga uso de ellas. No hay replicación alguna. Si queremos hacer tareas complejas son un poco limitadas. Un ejemplo claro se produce cuando en una misma sesión dos procesos en segundo plano utilizan una única variable global. Si modificamos el valor de la variable global en memoria en un proceso de segundo plano y ejecutamos al mismo tiempo otro proceso en segundo plano que haga uso de la variable el cambio afectará a todos los procesos ejecutados.
     

  6. [N1] correo.ceesa dice:

    Totalmente de acuerdo con Juan en el tema de los parámetros. Solucionaría dar muchos rodeos.

  7. Juan Figueroa dice:

    Como Rafa debe de estar en horario de verano, sigo preguntando para que me conteste todo al mismo tiempo:
    Si cargo una variable global en memoria (VGM) en un proceso en tercer plano o en el arranque de la aplicación en el Servidor, ¿la pueden ver y/o modificar todas las sesiones cliente y sigue estando visible para todas?, ¿cómo?, ¿es la misma VGM o una réplica? ¿Hay alguna diferencia en V7 con respecto a V6.x?
    ¿Qué inconvenientes tendría la existencia de VGMs exclusivas del Servidor que fuesen conscientemente visibles y/o modificables para todas las sesiones cliente?
    Si no existe inconveniente, conviértase la última pregunta en una sugerencia.
    Se echan en falta novedades importantes en la base de datos, como fueron en su tiempo en la V6. los punteros ‘singular de plural por posición o por índice’, ‘hermano contiguo’, etc…
    Por cierto, ¿qué fue de los índices complejos?
    Bueno, Rafa, ya tienes tarea y, por adelantado, gracias

  8. Nacho dice:

    Totalmente de acuerdo con Fran Varona.
    Está muy bien las variables locales, pero también tenemos que porder utilizar variables globales.
    Variables por sesión que puedan ser utilizadas tanto en local como en procesos de servidor.
     

Deja un comentario

Esta web utiliza cookies. Si continúa navegando acepta dichas cookies y nuestra política de cookies. Gracias. ACEPTAR

Aviso de cookies