Weidhtx, weighty – задають відносні розміри компонентів.

Будь-який з компонентів, що вимагає показу на екрані, повинний бути доданий у клас-контейнер. Контейнери служать сховищем для візуальних компонентів інтерфейсу й інших контейнерів. В awt визначено такі контейнери:

- вікно (Window);

- панель (Panel);

- фрейм (Frame);

- діалогове вікно (Dialog).
Навіть якщо в аплеті явно не створюється контейнер, він все рівно буде використовуватися, оскільки клас Applet є похідним від класу Panel.

Найпростіший приклад контейнера – клас Frame, об'єкти якого відображаються на екрані як стандартні вікна з рамкою.

Щоб показати компонент користувацького інтерфейсу у вікні, потрібно створити об'єкт-контейнер, наприклад, вікно класу Frame, створити необхідний компонент і додати його в контейнер, а вже потім відобразити його на екрані. Незважаючи на настільки довгий список дій, у вихідному тексті цей процес займає усього кілька рядків.

Як бачимо, створення меню хоча і тривалий, але зовсім не складний процес. В друге меню додається не пункт вибору класу MenuItem, а меню класу Menu. Це приводить до того, що при натисканні на пункт 2 смуги меню поруч з'являється наступне меню, вибравши з якого nextLevel Menu одержали чергове меню. На такий спосіб у Java реалізовано каскадне меню.

Обробка пунктів меню виконується за допомогою метода action(), де перший параметр – об’єкт класу Event, при цьому треба робити перевірку на приналежність до меню, а саме:
if (e.tsrget instanceof MenuItem) { ….. };

а другий параметр – назва вибраного пункту меню.
Сучасний підхід до обробки подій оснований на моделі делегування подій (delegation event model), яка визначає стандартні та непротирічні механізми для генерації та обробки подій. Ця концепція доволі проста: джерело генерує подію та посилає її одному або кільком блокам прослуховування (listeners) подій. За цією схемою блок прослуховування просто очікує на подію. Отримавши подію, блок прослуховування обробляє її та повертає управління. Перевага такого способу полягає в тому, що логіку компонента, який обробляє подію, чітко відокремлено від логіки інтерфейса користувача, що генерує ці події. Елемент інтерфейса користувача здатний “делегувати” обробку події окремій частині коду.
В моделі делегування подій блоки прослуховування мають зареєстру­ватися у джерелі, щоб приймати повідомлення про події. Це забезпечує важливу перевагу: повідомлення відсилаються тільки тим блокам прослуховування, які хочуть його прийняти. Це більш ефективний спосіб обробки подій, ніж старий метод, що використовується в Java 1.0. Раніше подія розповсюджувалася по обмеженій ієрархії компонентів, поки один з них не обробляв цю подію. Даний метод вимагає від компонентів прийняття подій, які вони не обробляють, на що витрачається певний час. Модель делегування подій усуває такі накладні витрати.
В моделі делегування подія – це об’єкт, який описує зміни стану дже­рела. Він може бути сгенерований як послідовність взаємодій оператора з елементами графічного інтерфейса користувача. Генерацію подій можуть ви­кли­кати такі дії оператора, як натиснення кнопки, введення символу з кла­ві­а­тури, вибір елемента в списку, клік мишею та інші дії. Крім того, програміст має змогу сам визначати події, які буде знаходити та обробляти його додаток.

Джерело – це об’єкт, який генерує подію. Генерація події відбувається тоді, коли змінюється внутрішній стан цього об’єкту. Джерела можуть генерувати події кількох типів.
Щоб блоки прослуховування мали змогу приймати повідомлення про певний тип подій, джерело має реєструвати ці блоки. Кожен тип подій має власний метод реєстрації. Загальна форма таких методів:
public void addTypeListener(TypeListener el)
де Type – це ім’я події, el – посилання на блок прослуховування події. Наприклад, метод, який реєструє блок прослуховування події клавіатури, називається addKeyListener(). Метод, що реєструє блок прослуховування руху миші, називається addMouseMotionListener(). Коли подія відбувається, всі зареєстровані блоки прослуховування повідомляються про це та прий­мають копію об’єкта події. За будь-яких умов повідомлення відсилаються тільки тим блокам прослуховування, які зареєструвалися для їх приймання.
Деякі джерела можуть дозволяти реєструватися лише одному блоку прослуховування. Загальна форма такого методу:
public void addTypeListener(TypeListener el) throws java.util.TooManyListenerException
Коли подія відбувається, про це повідомляється тільки цей зареєстрований блок прослуховування.
Джерело також має забезпечити метод, який дозволить блоку прослуховування не реєструвати зацікавленість у певному типі повідомлень. Загальна форма такого методу: public void removeTypeListener(TypeListenerel)
Наприклад, щоб видалити блок прослуховування клавіатури, слід викликати метод removeKeyListener().
Методи, які додають або вилучають блоки прослуховування, забез­печуються джерелом, що генерує подію. Наприклад, клас Component забезпечує методи для додавання та вилучення блоків прослуховування подій клавіатури та миші.
Блок прослуховування – це об’єкт, який отримує повідомлення, коли відбувається подія. До нього висувається дві головних вимоги. По-перше, щоб приймати повідомлення відносно певних типів подій, він має бути зареєстрованим одним або кількома джерелами цих подій. По-друге, він має реалізувати методи для приймання та обробки цих повідомлень.
Методи, що приймають і обробляють події, визначені в наборі інтерфейсів, що знаходяться в пакеті java.awt.event. Наприклад, інтерфейс MouseMotionListener визначає два методи для приймання повідомлень про події перетягування та пересування миші. Будь-який об’єкт може приймати та обробляти одну або обидві ці події, якщо він забезпечує реалізацію цього інтерфейса. [16]