Proyectos, paquetes y archivos EGL

Un proyecto EGL incluye de cero a muchas carpetas fuente, cada una de las cuales incluye de cero a muchos paquetes, y cada uno de éstos incluye de cero a muchos archivos. Cada archivo contiene de cero a muchos componentes.

Proyecto EGL

Un proyecto EGL se caracteriza por un conjunto de propiedades, que se describen más adelante. En el contexto de un proyecto EGL, EGL realiza automáticamente la validación y resuelve las referencias a componentes cuando se realizan determinadas tareas; por ejemplo cuando se guarda un archivo fuente EGL o archivo de construcción. Además, si trabaja con componentes PageHandler de VGUIRecords, EGL genera automáticamente la salida, pero sólo en este caso:
  • Ha establecido el proceso de construcción automático después de seleccionar las siguientes opciones: Ventana > Preferencias > Entorno de trabajo > Realizar construcción automáticamente en modificación de recurso
  • Ha establecido un descriptor de construcción por omisión como preferencia o propiedad

Un proyecto EGL se forma seleccionando EGL o Web EGL como tipo de proyecto cuando se crea un nuevo proyecto. Asigne las propiedades a medida que realiza los pasos de creación del proyecto. Para empezar a modificar las opciones después de completar estos pasos, pulse con el botón derecho del ratón en el nombre del proyecto y cuando se visualice un menú de contexto, pulse Propiedades.

Las propiedades de EGL son las siguientes:
Carpeta fuente EGL
Una o más carpetas de proyecto que son los directorios raíz de los paquetes del proyecto, cada uno de los cuales es un conjunto de subdirectorios. Una carpeta fuente es útil para mantener el fuente EGL separado de los archivos Java y para mantener los archivos fuente EGL fuera de los directorios de despliegue Web. Se recomienda especificar carpetas fuente EGL en todos los casos; pero si no se especifica una carpeta fuente, la única carpeta fuente es el directorio de proyectos.

El valor de esta propiedad se almacena en un archivo llamado .eglpath del directorio de proyectos y se guarda en el depósito (si existe) que se utiliza para almacenar archivos fuente EGL.

Cada uno de los asistentes de proyecto EGL crea una carpeta fuente llamada EGLSource.

Vía de acceso de construcción EGL
La lista de proyectos donde se busca algún componente que no se encuentra en el proyecto actual.

El valor de esta propiedad se almacena en un archivo llamado .eglpath del directorio de proyectos y se guarda en el depósito (si existe) que se utiliza para almacenar archivos fuente EGL.

En el siguiente ejemplo de un archivo .eglpath, EGLSource es una carpeta fuente del proyecto actual y AnotherProject es un proyecto de la vía de acceso EGL:
  <?xml version="1.0" encoding="UTF-8"?>
  <eglpath>
    <eglpathentry kind="src" path="EGLSource"/>
    <eglpathentry kind="src" path="\AnotherProject"/>
  </eglpath>

Las carpetas fuente de AnotherProject se determinan a partir del archivo .eglpath de dicho proyecto.

Descriptores de construcción por omisión
Los descriptores de construcción que permiten generar rápidamente la salida, como se describe en Generación en el entorno de trabajo.

Paquete

Un paquete es una colección con nombre de componentes fuente relacionados. El nombre es sensible a mayúsculas y minúsculas: myPkg es diferente de MYPKG.

Cuando se crean componentes de construcción no se utiliza ningún paquete.

Por convenio, la exclusividad de los nombres de paquete se consigue haciendo que la parte inicial del nombre de paquete sea el nombre de dominio de Internet de la organización con el orden invertido. Por ejemplo, el nombre de dominio de IBM es ibm.com y los paquetes EGL empiezan por "com.ibm". Utilizando este convenio, se tiene la seguridad de que los nombres de los programas Web que desarrolla una organización no duplicarán los nombres de programas desarrollados por otra organización y los programas podrán instalarse en el mismo servidor sin que exista la posibilidad de se produzca un conflicto de nombres.

Las carpetas de un determinado paquete se identifican mediante el nombre de paquete, que es una secuencia de identificadores separados por puntos (.), como en el siguiente ejemplo:
  com.mycom.mypack
Cada identificador corresponde a una subcarpeta de una carpeta fuente EGL. Por ejemplo, la estructura de directorios de com.mycom.mypack es \com\mycom\mypack, y los archivos fuente se almacenan en la carpeta más inferior; en este caso, en mypack. Si el espacio de trabajo es c:\miEspacioTrabajo, si el proyecto es nuevo.proyecto y si la carpeta fuente es EGLSource, la vía de acceso de este paquete es la siguiente:
  c:\miEspacioTrabajo\nuevo.proyecto\EGLSource\com\mycom\mypack

Todos los componentes de un archivo fuente EGL pertenecen al mismo paquete. La sentencia de paquete del archivo, si existe, especifica el nombre de dicho paquete. Si no se especifica una sentencia de paquete, los componentes se almacenan directamente en la carpeta fuente y se dice que están en el paquete por omisión. Se recomienda especificar siempre una sentencia de paquete ya que los archivos del paquete por omisión no pueden compartirse con los componentes de otros paquetes o proyectos.

Es posible que dos componentes con el mismo identificador no estén definidos en el mismo paquete. Se recomienda no utilizar el mismo nombre de paquete en diferentes proyectos o en diferentes carpetas.

El paquete para la salida Java generada es el mismo que paquete del archivo fuente EGL.

Archivos EGL

Cada archivo EGL pertenece a una de las siguientes categorías:

Archivo fuente
Un archivo fuente EGL (extensión .egl) contiene componentes lógicos, de datos y de interfaz de usuario y está escrito en formato fuente EGL.
Cada uno de los componentes generables siguientes puede transformarse en una unidad compilable:
  • DataTable
  • FormGroup
  • Manejador (la base de un manejador de informes)
  • Biblioteca
  • PageHandler
  • Programa
  • VGUIRecord

Un archivo fuente EGL puede incluir de cero a muchos componentes no generables pero no puede incluir más de un componente generable. El componente generable (si existe) debe estar en el nivel superior del archivo y debe tener el mismo nombre que el archivo.

Archivo de construcción
Un archivo de construcción EGL (extensión .eglbld) puede contener cualquier número de componentes de construcción y está escrito en XML (Extensible Markup Language), en formato de archivo de construcción EGL. Puede revisar la DTD relacionada, que se encuentra en el siguiente directorio:
dirInstalación\egl\eclipse\plugins\
com.ibm.etools.egl_versión
dirInstalación
El directorio de instalación del producto, como por ejemplo C:\Program Files\IBM\Rational\SPD\6.0. Si instaló y tuvo un producto de Rational Developer antes de instalar el producto que está utilizando ahora, deberá especificar el directorio utilizado en la instalación anterior.
versión
La versión instalada del conector; por ejemplo, 6.0.1

El nombre del archivo (como por ejemplo egl_wssd_6_0.dtd) empieza por las letras egl y un signo de subrayado. Los caracteres wssd hacen referencia a Rational Web Developer y Rational Application Developer, los caracteres wsed hacen referencia a Rational Application Developer para z/OS y los caracteres wdsc hacen referencia a Rational Application Developer para iSeries.

Después de añadir componentes a archivos, puede utilizar un depósito para mantener un historial de los cambios.

Recomendaciones

Esta sección ofrece recomendaciones para configurar los proyectos de desarrollo.

Para descriptores de construcción

Los proyectos de equipo deben asignar una persona como desarrollador de los descriptores de construcción. Las tareas que debe realizar esta persona son las siguientes:
  • Crear los descriptores de construcción para los desarrolladores de código fuente
  • Poner estos descriptores de construcción en un proyecto distinto de los proyectos de código fuente; y hacer que este proyecto distinto esté disponible en el depósito o que esté disponible mediante otros medios.
  • Pedir a los desarrolladores de código fuente que establezcan la propiedad descriptores de construcción por omisión en los proyectos, de modo que la propiedad haga referencia a los descriptores de construcción correspondientes.
  • Si un subconjunto pequeño de las opciones del descriptor de construcción (como por ejemplo para el ID de usuario y la contraseña) varía de un desarrollador de código fuente a otro, pida a cada desarrollador de código fuente que realice lo siguiente:
    • Codificar un descriptor de construcción personal que utilice la opción nextBuildDescriptor para que señale a un descriptor de construcción de grupo.
    • Pedir a los desarrolladores de código fuente que establezcan la propiedad descriptores de construcción por omisión en los archivos, carpetas o paquetes, de modo que la propiedad haga referencia al descriptor de construcción personal. La propiedad no se especifica a nivel de proyecto ya que la propiedad a nivel de proyecto está bajo el control del depósito, junto con otra información del proyecto.

Para obtener información adicional, consulte la sección Componente descriptor de construcción.

Para paquetes

Para paquetes, las recomendaciones son las siguientes:
  • No utilice el mismo nombre de paquete en diferentes proyectos o directorios fuente
  • No utilice el paquete por omisión

Asignación de componentes

En el caso de los componentes, muchas de las recomendaciones hacen referencia a una buena práctica y no a requisitos estrictos. Siga incluso las recomendaciones opcionales a menos que tenga un buen motivo para no hacerlo:
  • Un requisito cuando utiliza PageHandlers es que ponga los JSP en el mismo proyecto que los PageHandlers asociados.
  • Si un componente no generable (como un componente de registro) sólo es utilizado por un programa, biblioteca o PageHandler, coloque el componente no generable en el mismo archivo que el componente que lo utiliza.
  • Si se hace referencia a un componente desde diferentes archivos del mismo paquete, ponga dicho componente en un archivo distinto del paquete.
  • Si un componente se comparte entre varios paquetes de un único proyecto, coloque dicho componente en un paquete distinto de dicho proyecto.
  • Ponga el código para aplicaciones sin absolutamente ninguna relación entre ellas en proyectos distintos. El proyecto es la unidad para transferir el código entre la estructura de directorios local y el depósito. Diseñe una estructura de proyecto de modo que los desarrolladores puedan minimizar la cantidad de código que tienen que tener cargado en el sistema de desarrollo.
  • Asigne nombres a los proyectos, paquetes y archivos de tal forma que se refleje el uso de los componentes que contienen.
  • Si el proceso enfatiza la propiedad del código por parte de un desarrollador, no asigne componentes de diferentes propietarios al mismo archivo.
  • Asigne componentes a paquetes con una descripción clara de la finalidad del paquete; y agrupe dichos componentes de acuerdo con relación de la proximidad entre ellos.
    La siguiente distinción es importante:
    • El hecho de mover un componente de un archivo a otro dentro del mismo paquete no obliga a cambiar las sentencias import en otros archivos.
    • El hecho de mover un componente de un paquete a otro puede hacer necesario añadir o cambiar una sentencia import en cada archivo que haga referencia al componente que se ha movido.
Comentarios
(C) Copyright IBM Corporation 2000, 2005. Reservados todos los derechos.