sep 5

¿Función o proceso?

En Velneo V7, como en la mayoría de los lenguajes y herramientas de programación, hay problemas que podemos resolverlos de distintas formas y obtener el mismo resultado.

La diferencia no esta en el resultado en si, que de un modo u otro será el mismo, la verdadera diferencia está en usar el método óptimo para llegar a ese resultado.

Y es aqui, donde se nos plantea la siguiente duda, en multitud de ocasiones, para solucionar un problema, podemos usar una “Función” o un “Proceso”.

A fin de cuentas, una “Función” es muy similar a un “Proceso” en muchos aspectos, aunque también tienen algunas diferencias

La función:

  • Permite hasta 10 parámetros de entrada, aunque esa barrera ya la habiamos superado cuando se publicó este articulo: Parámetros en funciones de V7
  • Tiene un parámetro de salida, aunque también habiamos solucionado este problema encadenando los valores (en el mismo artículo).
  • La función no tiene una tabla de origen, y tampoco destino.

El proceso:

  • Podemos usar tantos parámetros como necesitemos, eso si, usando el manejador de objetos para poder pasar y recibir parámetros.
  • Podemos obtener varios valores de retorno.
  • No es necesario indicar todos los parámetros en la llamada, solo aquellos que sean realmente necesarios.
  • El proceso puede ser: sin origen, o con origen y destino en una misma tabla (de tipo ficha o lista) dependiendo de donde lo vayamos a llamar.

Veamos ahora un ejemplo real que podriamos usar para solucionar un problema común:

La función:

El proceso:

Como podemos observar, las dos imagenes representan lo mismo:

Pasamos como parámetros de entrada los campos #ALM (almacén) y #ART (artículo), y comprobamos si existe el registro en la tabla de “Stock”, y si no existe, lo creamos. Al finalizar retornamos el #ID del registro creado (esto no es necesario pero se ha incluido para ver el retorno de valores).

Ademas, la definición es practicamente igual:

  • Las mismas variables en el panel de subobjetos
  • Las mismas instrucciones en el editor central
  • Y el mismo origen, en el panel de propiedades, aunque en el caso del proceso, esto puede cambiar.

Hemos visto como se definen las funciones y los procesos, pero como sería la llamada para ejecutarlos, porque aqui es donde realmente se diferencian:

En el caso de la función, la llamada es asi:

Necesitamos una variable a la cual asignamos el resultado que retorna la función, y despues, llamamos a la función pasandole todos los parámetros que necesita.

En el caso del proceso, la llamada mediante el manejador de objetos es asi:

La llamada mediante el manejador de objetos es un poco más compleja, ya que hay que definir el objeto en el manejador, luego asignar los valores a las variables con SET, después, ejecutar el proceso y, en último lugar, recoger los valores retornados con GET.

A la vista de los ejemplos, podemos ver que el uso de uno u otro método es aconsejable en los siguientes casos:

  • La función es obligatoria cuando necesitemos hacer uso de ella desde un contenido inicial.
  • El proceso es recomendable cuando necesitemos muchos parámetros o vayamos a retornar varios valores.
  • El proceso es obligatorio si queremos ejecutar en 3º plano.
  • El proceso es recomendable cuando los parámetros de entrada no sean obligatorios

Gracias por la visita y hasta pronto.

PDF Download    Enviar artculo en formato PDF   
comments: 6 »
oct 17

Como acercarnos al MVC

Posted in procesos

Continuación del artículo:

MVC en Velneo V7

A estas alturas de desarrollo de Velneo V7, tengo que decir que lo veo poco viable, pero como no hay nada imposible, voy a dejar aqui una de mis habituales ideas chorras.

Y antes de entrar en detalles vamos a comparar, que es un “Proceso” y que es un “Evento”, pero dejando claro que en adelante, al referirme a Eventos lo hago siempre pensando en los objetos del proyecto de aplicación, quedando excluidos por tanto los “Eventos de tablas” ya que nada tienen que ver con el interfaz:

  • Proceso es, una secuencia de instruciones que se ejecutan en orden secuencial y siguendo las normas de programación estructurada similares a las de cualquier otro lenguaje de programación. Esto quiere decir, que también disponemos de bucles, condiciones, y otras estructuras de flujo que funcionan exactamente igual que en los lenguajes de 3 generación.
  • Evento es, un proceso asociado a un objeto del interfaz de usuario, como puede ser un formulario, una rejilla, etc.

Y en que se asemejan los Procesos y los Eventos, si nos atenemos a esta definición:

  1. Los procesos y los eventos son exactamente iguales en cuanto a la forma de programar y ejecutar. De echo, todas las sentencias que podemos utilizar en los procesos, también están permitidas en los eventos, aunque esto no sucede a la inversa.
  2. Ambos tienen un Origen, que puede ser Ninguno, o una Tabla del proyecto de datos y en caso de ser una tabla, el origen puede ser de Ficha o de Lista
    • Los eventos también pueden ser sin origen, ya que tenemos Formularios Sin origen y en ellos también podemos definir eventos
    • El origen Ficha nos permite poder utilizar un evento en un Formulario y el origen Lista nos permite utilizarlo en objetos de tipo Lista como las Rejillas.

Ahora que ya conocemos las similitudes, ¿cuales son las diferencias?

  1. Los Eventos van siempre asociados a un objeto del interfaz y por tanto se ejecutan siempre en 1º plano, pero desde el evento tambien podemos llamar a otros objetos en 3º plano
  2. Los Eventos, al estar asociados a un objeto del interfaz, permite hacer uso de todas las sentencias de Interfaz, que en los Procesos aparecen desactivadas.
  3. El Proceso es un objeto y el Evento es un Subobjeto de un objeto del proyecto de aplicación.

Inicialmente, la idea de este artículo fué:

Si son tan parecidos, porque no crear un nuevo objeto llamado “Evento” pero externo al objeto, y que nos permita usar las sentencias de Interfaz.

Y una vez creado este objeto, podriamos llamarlo desde varios formularios o varias rejillas (siempre que el origen del Evento se corresponda con el Objeto que lo llama).

De esta forma, el objeto Formulario no necesitaria tener definidos los eventos, solo las “Conexiones de evento” y llamariamos al “Evento” como un objeto independiente y externo al objeto que lo ejecuta.

También pense:

El mismo objeto “Proceso”, seria viable para esta tarea, simplemente con añadirle una nueva propiedad que lo diferencie de los procesos habituales, y que activará las sentencias de interfaz.

Luego podriamos llamar a estos procesos de la misma forma que indiqué anteriormente.

Y finalmente me di cuenta de que,

  • el Evento debe ir unido al objeto, porque al activar las sentencias de Interfaz, con ellas podemos hacer uso de los controles incluidos en cada uno de los objetos (formularios, rejillas, etc.), es decir, desde un Evento puedo usar un control de edición del formulario que lo ejecuta, y ¿que pasa si utilizo el mismo Evento para 2 formularios de la misma tabla (que ésta erá la idea inicial) pero en uno de los formularios no existe dicho control de edición?. Pues que habría problemas, ¡seguro!

Asi pues, desisti de mi idea y de poner esta posibilidad en el “Foro de ideas” y por tanto, de acercarnos un poco mas al MVC,

Pero a veces, de las ideas equivocadas, también sale algo bueno, y en este caso, ha mi me ha servido como escusa perfecta para ver las diferencias y similitudes que existen entre Procesos y Eventos y desarrollar este artículo.

Y llegados a este punto, solo hay una conclusión lógica o moraleja que podemos sacar de este estudio.

Podemos cambiar al protagonista de nuestra peli de espias por cualquier otro (el Modelo) … James Bond, Super Agente 86, Am Brosio, y con ello conseguiremos mejorar notablemente la calidad de la información que guardamos en nuestra base de datos.

Pero, lo que no podemos es, separar la información obtenida (la Vista) y la forma de obtener dicha información: los mamporros, las amenazas y demas (el Controlador).

Imaginaos ahora un espia, que a la primera de cambio, le preguntamos, y sin necesidad de iniciar una tortura como dios manda, nos suelta todo lo que sabe. En este caso ya no estariamos hablando de espias, estariamos hablando de agentes dobles y eso quizá merezca otra historia, pero hoy no, ¡mañññaaaaannnnnaaaaa!

😉

PDF    Enviar artculo en formato PDF   
comments: 1 »