Cómo compilar paso a paso

Cuando un centro es modificado, bien sea mediante cambios en el diccionario o mediante cambios en el modelo, es necesario realizar una serie de operaciones para que los cambios realizados se vean reflejados en la aplicación egExplorer.

En este artículo abordaremos aquellos aspectos que influyen en dichas modificaciones, así como los pasos a seguir en función de qué elementos o ficheros del modelo se modifiquen. Para ello, es necesario conocer qué ficheros intervienen en el funcionamiento de un centro, y cómo afectan a éste.

Ejecutando egCompiler

Al crear un proyecto nuevo o modificar uno ya creado, la primera operación a realizar es compilar el proyecto. Si no se encuentran errores en la compilación, nuestro compilador, egCompiler, generará dos ficheros: un diccionario cuya extensión es .ndc y un modelo con extensión .nmc.

Pero, ¿y cómo ejecutamos el compilador?

Para ejecutar el compilador, hay que indicar ciertos parámetros de entrada, ya que el compilador necesita cierta información del proyecto para poder realizar el proceso de compilación.

En concreto, hay un parámetro de entrada fundamental para el compilador, que es el fichero .npc (código de proyecto).

En este fichero se indican, entre otras cosas, la correspondencia entre las definiciones realizadas en ODL, con los ficheros .ndf donde están declaradas. Cualquier definición o fichero .ndf nuevo que se genere deberá ser introducido por el programador en este fichero. Por tanto, deberemos indicar como primer parámetro la ruta de dicho fichero .npc.

Además de este parámetro, que es el único que realmente necesita el compilador, existen otros parámetros opcionales, de forma que podamos configurar ciertos aspectos del compilador. Veamos cuales son:

• /O: --> Indicaremos el diccionario previo a la compilación para compararlo con el nuevo diccionario a generar.
• /N: --> Indicaremos el directorio de definiciones.
• /D: --> Indicaremos el directorio destino donde queramos que se generen el diccionario(.ndc) y el modelo(.nmc). En caso de no especifircarlo se almacenarán en el directorio donde se encuentre el fichero .npc.
• /S: --> Su inclusión indica que solamente se genere el diccionario y no el modelo.

Una vez conocidos los parámetros que admite egCompiler, utilizaremos la consola del sistema para ejecutarlo. De esta manera podremos introducir los parámetros que nos interesen en cada ejecución. Veamos un ejemplo:

Compilación mediante la consola del sistema

Como habrás visto, lo primero es indicar la ruta del ejecutable del compilador. A continuación, especificamos la ruta del fichero .npc y, seguidamente, añadimos los parámetros opcionales. En este caso, hemos indicado con el parámetro /O: la existencia de un diccionario previo con el que vamos a comparar el nuevo a generar. Con el parámetro /D: indicamos una ruta donde queremos guardar los ficheros de salida que generará el compilador, que en este caso será sólo el diccionario, ya que la inclusión del parámetro /S: así lo indica.

NOTA: En caso de incluir rutas con espacios en blanco en ellas, debemos acotar la ruta completa entre comillas dobles.

Configuración de egCompiler en EditPlus

Es probable que la persona que esté desarrollando en ODL tenga que realizar numerosas y repetitivas compilaciones en su proyecto. Por ello, facilitamos una forma de configurar el egCompiler en un editor de programación, que en este caso, hemos optado por el EditPlus. Sin más preámbulos, veamos cómo configurar dicho editor para ejecutar directamente el compilador desde él:

• Primer paso: ir a Tools -> Preferences:

Tools -> Preferences

• Segundo paso: dentro de Preferences, ir a la etiqueta User tools:

Entrar en User Tools

• Tercer paso: una vez en User tools, hay varias opciones y campos que debemos configurar. En primer lugar, vemos que existen varios grupos. Seleccionamos uno de ellos, y para cambiar el nombre haremos clic en Group Name.... Estos grupos sirven para etiquetar conjuntos de herramientas que definamos en EditPlus, como por ejemplo, en nuestro caso, la configuración del compilador:

Editar el nombre de un grupo

• Cuarto paso: ahora tenemos que crear una herramienta. Para ello, hacemos clic en Add Tool >>. Nos aparecerá un desplegable, donde seleccionaremos Program para indicar que vamos a configurar una aplicación:

Añadimos una herramienta, en este caso, nuestro compilador

• Quinto paso: vemos que hay ciertos campos como Menu text, Command, Argument o Initial directory además de ciertas opciones activables:

Introducir datos necesarios para la ejecución del compilador

En Menu text pondremos el nombre que aparecerá en el menú de herramientas para ejecutar el compilador.

En Command introduciremos la ruta en donde está almacenado el ejecutable del egCompiler.

En el campo Argument podremos especificar los argumentos que acepta el egCompiler. En nuestro caso, añadiremos el parámetro /O: (además del fichero .npc como explicamos en el apartado anterior) para que al compilar compare el diccionario previo con el nuevo creado, de manera que pueda detectar los cambios.

A continuación, añadiremos en el campo Initial directory el directorio donde se encuentra el fichero .npc (si no indicamos el directorio destino con el parámetro /D: el compilador almacenará el diccionario y el modelo en este directorio).

Finalmente, activaremos las casillas Capture output para ver los mensajes de compilación en el propio EditPlus (en vez de en una ventana) y Save open files para que al compilar se guarden los ficheros abiertos del proyecto en cuestión. Los ficheros abiertos que no pertenezcan al proyecto no se guardarán.

Ahora veremos que la opción Compilar estará disponible en el menú Tools o Herramientas:

El compilador ya se puede utilizar desde EditPlus

Compilando...

Una vez hemos ejecutado nuestro compilador, bien mediante la consola del sistema, o bien mediante un editor, el compilador informará al programador de aquellas definiciones que, o bien son nuevas y puede generar un DRC en la base de datos para cada una de ellas, o bien detecta definiciones anteriores que ya no se encuentran en el código (en comparación con un modelo anterior) y, por tanto, es posible la liberación de su DRC. Existe otra operación, que es asignar el DRC de una definición que vamos a eliminar a una nueva que vamos a generar. De esta forma conservamos los valores que se han creado a partir de la definición que vamos a eliminar.

Como ya sabemos, una vez liberados, generados o asignados los DRCs, el compilador generará un diccionario y un modelo.

Veamos un ejemplo práctico:

• En primer lugar, vamos a generar por primera vez nuestro modelo, de forma que se generará un DRC para todas las definiciones. Podemos ir generando las nuevas definiciones seleccionando de una en una con el botón Generar, o bien utilizar el botón Generar todos.

  Nuestro sistema de información está constituído por dos definiciones de tipo (Cliente y Expediente) con sus respectivas colecciones (Clientes->Contenido) y Expedientes->Contenido). Además también hay definida una habitación Mi organización para ubicar dichas colecciones y una definición de rol para acceder a los recursos definidos:

Generamos los DRC de las definiciones por primera vez

• Ahora, hemos decidido eliminar ciertas definiciones, de forma que, al compilar, se comparará el diccionario creado en el paso anterior con el nuevo, y detectará aquellas definiciones que ya no se encuentren en el código. Al igual que al generar DRCs, existe un botón para ir liberando uno a uno cada DRC mediante el botón Liberar o bien liberarlas todas automáticamente, sin tener que seleccionar ninguna, con el botón Liberar todas:

Eliminamos la definición de tipo Expediente, así como todo aquello relacionado con dicha definición (colección, ubicación y permisos)

• La tercera posibilidad que nos podemos encontrar es la asignación de un DRC, correspondiente a una definición que vamos a eliminar, a una definición nueva que vamos a generar. En este caso debemos tener en cuenta las posibilidades que se nos pueden presentar, pues pueden ser varias.

  Normalmente, esta operación se suele realizar al cambiar el nombre de alguna definición, de forma que nos puede interesar asignar el DRC de la definición anterior a la nueva definición para que los valores generados anteriormente al cambio de nombre se mantengan en la nueva definición.

  Otra posibilidad es, por ejemplo, cambiar el tipo de un campo. En este caso, se podrá asignar el DRC del campo previo al nuevo campo, pero las consecuencias de dicho cambio tendrá que valorarlas el programador, pues puede no conseguirse el efecto deseado.

  Un nuevo caso, en el que vamos a basar nuestro ejemplo, puede ser el cambio de nombre de un formulario, junto con el cambio de nombre de un campo incluído en dicho formulario. En cuanto a los formularios, hay que tener en cuenta que deben tener el mismo número de campos, además, los campos deben tener el mismo nombre.

  Vayamos viendo los pasos a realizar uno a uno, de manera que los vayamos comentando:

Relación de las definiciones a liberar o a generar

Vemos que el compilador ha detectado definiciones que, o bien pueden ser liberadas, o bien pueden ser generadas. Pero nuestra intención es asignar el DRC del formulario Datos generales al formulario Datos generales del cliente. Además, ha detectado que el campo DNI ha cambiado de nombre, detectando un nuevo campo denominado NIF así como el cambio de nombre de la columna DNI de la colección Clientes por NIF:

Primero seleccionamos la definición del DRC que vamos a asignar

Seleccionamos la definición nueva, indicando que el DRC será asignado a esa definición

Y generamos la asignación con el botón Asignar

Ya tenemos realizada la asignación de la columna que ha cambiado de nombre en la colección Clientes. Ahora vamos a asignar el formulario. Para ello, hay que tener en cuenta que un campo ha cambiado de nombre, y, por tanto, deberemos asignar dicho DRC antes de hacerlo con el formulario:

Seleccionamos el campo que contiene el DRC

Seleccionamos el campo nuevo

Y generamos la asignación, al igual que en el caso anterior

Una vez tratado el campo que ha cambiado de nombre, ya no hay restricciones para asignar el DRC del formulario Datos generales al formulario Datos generales del cliente:

Seleccionamos el formulario que contiene el DRC

Seleccionamos el formulario nuevo

Y realizamos la asignación

¿Y qué pasa si introduzco, elimino o modifico un atributo en alguna definición? Los atributos no tienen asignado un DRC, por lo que cualquier edición que hagamos sobre ellos, el compilador no detectará posibles modificaciones en los DRC del sistema.

Crear un fichero de proyecto (.npc)

Como ya hemos comentado en este artículo, a la hora de compilar un proyecto en ODL es necesario especificar el fichero .npc en el egCompiler.

Este fichero deberá ser creado manualmente por el desarrollador, por lo que vamos a explicar a continuación la información que debe almacenar, la estructura que tiene que adoptar y las funciones para las cuales está destinado este fichero.

Cuando instalamos un centro, la estructura de directorios que tendrá el centro una vez instalado está predefinido en un modelo por defecto llamado (Default), que tiene la siguiente estructura:

Compilación mediante la consola del sistema

En nuestro directorio de desarrollo, crearemos aquellas carpetas (que existan en el modelo Default) que vayamos a modificar. Por ejemplo, si nuestro centro tiene escritos, tendremos que crear una carpeta llamada Template documents, donde almacenaremos los ficheros .rtf de nuestro centro.

Una vez creado el modelo del centro, lo instalaremos mediante el egAdmin. Éste comparará el modelo Default con nuestro modelo de centro, de manera que las carpetas que se encuentren en ambos modelos serán fusionadas. Es decir, que, por ejemplo, la carpeta Template documents, donde hemos añadido los ficheros rtf, aparecerá con los ficheros rtf en el directorio de explotación del centro (y no vacío como aparece en el modelo Default).

Pero, ¿y cómo interviene el fichero .npc en todo este proceso de compilación e instalación de un centro?

El fichero .npc tiene varias funciones en todo este proceso.

Por un lado, informará al compilador de las definiciones que serán compiladas y de las cuales saldrá el diccionario resultante. Por otro lado, informará al compilador de aquellas carpetas que se han creado en el directorio de desarrollo y que se quieren incluir en el modelo de centro para su posterior instalación. Por ello, es un fichero fundamental para la compilación de nuestro centro.

La estructura de un fichero .npc debe ser la siguiente:

Compilación mediante la consola del sistema

Las palabras enmarcadas en verde son palabras clave que deben ir en el fichero.

Para el caso de la cabecera, añadiremos un campo donde añadiremos un nombre.

En todos los centros, es necesario crear al menos un fichero de constantes básicas. Este fichero .nc deberá ir especificado en la palabra clave Constantes. En caso de existir más de un fichero, se especificarán uno debajo de otro.

En caso de querer especificar una carpeta de plantillas de escritos, plantillas de impresión o plantillas de vistas, lo haremos en las palabras clave Plantillas_documentos para la carpeta [Template documents], Plantillas_visualizacion para la carpeta [Template views] o Plantillas_impresion para la carpeta [Template prints].

Hay que tener en cuenta que el directorio de las carpetas se especifica a partir del directorio donde esté alojado el fichero .npc. Si la carpeta [Template documents] está en la misma carpeta que el fichero .npc, no habrá que añadir ninguna ruta.

Por último, tendremos que especificar las definiciones para generar el diccionario. Esto lo haremos bajo la palabra clave Definiciones. Para ello, indicaremos el nombre de la unidad de cada fichero .ndf con el directorio donde se encuentra el fichero .ndf, tal y como hemos podido ver en la imagen anterior.

Crear un fichero de constantes (.nc)

Otro tipo de fichero que tiene que ser creado por el desarrollador son los ficheros de constantes (.nc). Estos ficheros especifican las constantes que se utilizan en un centro.

Existen ciertas constantes básicas que deben ser incluidas en un fichero que tiene que llamarse CBasicas.nc. Estas constantes básicas coinciden en etiqueta con algunas palabras reservadas del propio lenguaje ODL. Esto es así porque en el proceso de compilación las definiciones se crearán en función de los valores de las constantes y no de sus etiquetas.

Por ejemplo, en el conjunto de estas constantes básicas, existe una cuya etiqueta es ENTERO, que tiene valor 1. Cuando en nuestro código ODL definimos un campo entero, en el proceso de compilación la definición del campo será creada con el valor de la constante y no de la etiqueta. A continuación, cuando ejecutemos la aplicación egExplorer, que cargará el diccionario generado por el compilador, leerá que existe una definición de campo con valor 1, que interpretará como un campo entero.

Para que este comportamiento se lleve a cabo, debe existir una referencia en el fichero .npc al fichero .nc de constantes básicas. Esto es debido a que el parámetro que se le pasa al compilador es el fichero .npc de nuestro proyecto.

Aparte de las constante básicas, es posible que el desarrollador quiera declarar nuevas constantes. Esto podrá hacerlo en el mismo fichero CBasicas.nc o crear otros ficheros .nc para agrupar estas constantes. En caso de crear nuevos ficheros .nc, debemos incluirlos siempre en el fichero .npc.

A continuación, mostramos todas aquellas constantes básicas que son necesarias en cualquier centro:

Para incluir nuevas constantes en el fichero, simplemente hay que seguir el formato visto en la imagen, pudiendo declararlas en cualquier parte del fichero. Únicamente habrá que tener cuidado de modificar las constantes básicas o declarar nuevas constantes con etiquetas ya utilizadas.

¿Actualizamos el diccionario, el modelo o el centro?

Cuando realizamos modificaciones en algunos de los elementos que constituyen el modelo de un sistema de información, es necesario utilizar la aplicación egAdmin para actualizar los cambios que hemos realizado y que se reflejen en la herramienta egExplorer. En función de los cambios realizados, será necesario actualizar el diccionario, el modelo o el centro.

Por tanto:

• ¿Cuándo debo actualizar sólo el diccionario?

  Actualizaremos el diccionario cuando modifiquemos una definición de tipo o creemos una definición de tipo nueva en los ficheros .ndf que se encuentran en el directorio #Source

Actualizar diccionario en egAdmin

• ¿Cuándo debo actualizar sólo el modelo?

  Si cambiamos o agregamos algún fichero .rtf (plantillas), .nmt (métodos), .csv (representación de datos), scripts SQL, etc. Es decir, todo aquello que no sea un fichero .ndf.

Actualizar modelo en egAdmin

• ¿Cuándo debo actualizar el diccionario y el centro?

  Actualizaremos el diccionario y el centro cuando incluyamos nuevas definiciones de sistema. Además, cuando creamos tablas nuevas en la base de datos (por ejemplo, nuevas colecciones) o cualquier cambio que afecte a la base de datos. Este caso tiene una particularidad, y es que al tener que actualizar el centro, deberemos pararlo previamente, y una vez actualizado, arrancarlo nuevamente.

Actualizamos primero el modelo

A continuación paramos el centro en el botón Parar

Lo actualizamos y arrancamos en el botón Arrancar

• ¿Cuándo debo actualizar el diccionario y reiniciar el centro?

  Cuando cambiamos el nombre a la definición de una tarea o definimos una nueva en nuestro código ODL, evidentemente tendremos que actualizar el diccionario. Pero, a diferencia del primer caso, en el que sólo tenemos que actualizar el diccionario, también es necesario parar el centro y volver a arrancarlo (reiniciarlo), pero sin actualizarlo.