Introducción a Composite UI Application Block (CAB) II

Comienzo de la aplicación CAB

La base de toda aplicación CAB es la clase CABApplication. Posee el código para, entre otras cosas, agregar servicios globales, construir, inicializar y ejecutar el RootWorkItem, cargar todos los módulos especificados en el catálogo, comenzar la aplicación iniciando el loop de mensajes (eso dependerá del tipo de aplicación que sea) y por último ejecutar el código de dispose (cuando esta finaliza). Sobre esta clase se monta la jerarquía de clases que se muestra en la Figura 1.

Figura 1

Jerarquía de clases del Shell.

·         CabApplication: Esta clase, como se mencionó anteriormente, se encarga de administrar los pasos fundamentales de la inicialización de Composite UI Application Block. Es utilizada por todos los tipos de shell y sólo requiere como parámetro la clase que se usará como RootWorkItem.

·         CabShellApplication: Se usa en aplicaciones que necesitan un shell. Incorpora dos métodos virtuales BeforeShellCreated() y AfterShellCreated(). Estos métodos son llamados antes y después de la creación del shell con el RootWorkItem.

·         WindowsFormsApplication: Es usada en todos los shell que utilizan Windows Forms. Incorpora algunas tareas a la etapa de inicialización, como agregar Builder Strategies que manejará el ObjectBuilder y registrar un visualizador, entre otras cosas.

·         FormShellApplication: Sobrescribe el método Start() de CABApplication y llama al método Application.Run() (requerido por los Windows Forms) pasándole el shell. Esta clase es usada por aplicaciones que necesitan mostrar un formulario prinicipal.

·         ApplicationContextApplication: Esta clase se usa en aplicaciones de Windows que no necesitan mostrar un shell durante la etapa de inicialización. Además del RootWorkItem, esta clase recibe como parámetro una clase que herede de ApplicationContext. La clase ApplicationContext se encarga de controlar la aplicación principal y las circunstancias que causan la salida del loop de mensajes. Se usa en aplicaciones que se cargan como plug-ins en otros sistemas como por ejemplo los Office Add-in. También sobrescribe el método Start() de CABApplication y llama a Application.Run() pero le pasa el ApplicationContext antes mencionado.

Toda aplicación CAB comienza en el método Run() de la clase CABApplication. La Figura 2 ilustra las prinicipales tareas del flujo de inicialización.

Figura 2

Inicialización de CAB.

• Se crea el ObjectBuilder y se le agregan las Builder Strategies.
• Se crea e inicializa el RootWorkItem. Esta instancia será usada desde todos los módulos para crear objetos y acceder a partes del shell (Workspace y UIElements).
• Se agregan todos servicios al RootWorkItem
• Se llama al servicio de autenticación (Authentication) el cual es responsable de verificar el rol del usuario en el dominio de la aplicación.
• Se buscan y cargan los módulos especificados en el Catálogo en la secuencia correcta. Se busca una clase que implemente la interfaz IModule.
• Se cargan los servicios propios de cada módulo y se llama al método Load() de la clase de entrada.
• Se ejecuta el RootWorkItem invocando a su método Run().
• Se invoca el método Start() encargado de mostrar el formulario principal. Este método retorna el control solo cuando la aplicación finaliza (FormShellApplication) o cuando el contexto en la que estaba finaliza (ApplicationContextApplication).

• Al finalizar el método Start() se hace un dispose.

En el siguiente informe se explicará el proceso de carga de un módulo y cómo aplicar el patrón Model-View-Presenter (MVP) con Composite UI Application Block.