## Detalles de la Arquitectura de Componetes

El AWT fue diseñado desde el principio para tener un API independiente de la plataforma y aún asó preserva el aspecto y el comportamiento de cada plataforma. Por ejemplo, el AWT sólo tiene un API para los botones (proporcionado por la clase Button), pero un botón es diferente en un macintosh o en un PC bajo Windows 95.

El AWT cosigue este objetivo ligeramente contradictorio proporcionando la clase (component) que proporciona un API independiente de la plataforma para asegurarse de que utiliza las implementaciones especificas de las plataformas, los (pares). Para ser especificos, cada clase componente del AWT (Component, MenuComponent, y sus subclases) tiene una clase par equivalente, y cada objeto componente tiene un objeto par que controla el aspecto y comportamiento del objeto.

Los pares de los botones son implementados en clases especificas de las plataformas que implementa el inteface ButtonPeer de java.awt.peer. La clase java.awwt Toolkit define métodos que eligen exactamente la clases a utilizar por la implementación del par.

### Cómo se crean los Pares

> Los Pares son creados justo antes de que su objeto componente correspondiente sea dibujado por primera vez. Podrías haber observado un efecto laterar de esto: el tamaño de un componente no es válido hasta después de que el componente no se haya mostrado por primera vez.

> Cuando se añade un componente a un contenedor no visible (un contenedor sin par), justo antes de que el contenedor se muestre por primera vez, su par, -- y los pares de todos los componentes que contiene -- son creados.

> Sin embargo, si se añade un componente a un contenedor visible, necesitas decirle explícitamente al AWT que cree un par para el componente. Puedes hacer esto llamando al método validate(). Aunque se puede llamar a este método directamente sobre el componente que se está añadiendo, normalmente se invoca sobre el contenedor. La razón para esto es que llamar a validate() de un contenedor causa una reacción en cadena -- todos los componetes del contenedor también obtienen su validación. Por ejemplo, después de añadir componentes a un objeto Applet, se puede llamar el método validate() del Applet, el cual creará pares para todos los componentes del Applet.

### Cómo manejan los Eventos los Pares

> Los Pares implementan el comportamienteo (e, indirectamente, el aspecto) de los componentes del UI para reaccionar ante los eventos del usuario. Por ejemplo, cuando el usuario pulsa un botón, el par reacciona a la pulsación y la liberación del botón del ratón haciendo que el botón parezca que ha cambiado su aspecto y enviándo el evento Action al objeto Button apropiado.

> En teoría, los pares están al final de la cadena de eventos. Cuando ocurre un evento (como una pulsación de tecla), el Componente para el que se ha generado el evento obtiene el manejo para el evento, y luego (si el controlador de eventos del componente devuelve false) el Contenedor del Componente vee el evento, y así sucesivamente. Después de que todos los componentes del árbol hayan tenido la oportunidad de manejar el evento (y todos sus controladores de evento hayan devuelto false), llega al par y éste puede ver y reaccionar al evento.

> En la implementación actual, el escenario anterior es verdad para las pulsaciones de teclas pero no para los eventos del ratón. Para los eventos de ratón, el par es el primero en ver el evento, y no necesita pasar todos los eventos al componente. Planeamos hacer que los eventos de ratón trabajen de la misma forma que los del teclado en una futura versión.

> Para procesos como pulsaciones de teclas o del ratón, los pares algunas veces general eventos de nivel superior -- action, focus, change, minimización de ventanas, etc. Estos eventos de alto nivel se pasan al componente relevante para su manejo.

Ozito