Вход:  Пароль:  
FreeSource: AltLinux/Sisyphus/Alterator/evolution ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.

Простейший язык описания интерфейсов

(всё описанное касается alterator версии 2.9 и старше)


Документ – основной кирпичик в построении интерфейса. Каждый документ есть виджет, и наоборот, каждый виджет есть некоторый документ. Простейшие документы представляют простейшие виджеты, например, кнопку, метку и так далее. Документы сложнее, композиция простейших, представляет комплексные виджеты – самостоятельные части диалога с пользователем. Кроме того каждый документ можно рассматривать ещё как некоторую программу на простом подмножестве языка программирования Scheme. Ну обо всём по порядку.

1. Документ как файл


Документ прежде всего текстовый файл, размещающийся где-то на файловой системе.
Документы адресуются любым распространённым способом: через указание полного пути, через URI по правилам RFC-3986, через URI по правилам alterator.

2. Документ как программа


Во вторую, как не странно, очередь документ это программа на подмножестве языка программирования Scheme.
Прежде чем мы увидим графическое воплощение документа, он загружается и исполняется интерпретатором.
Как в каждом языке программирования, часть документа можно скрывать от интерпретатора – делать комментарии.
Остаток строки после символа “;" интерпретатором не рассматривается. В дальнейшем изложении мы будем пользоваться комментарием для добавления пояснений в текст примеров.


C этой точки зрения документ представлен как множество вложенных друг в друга окружений. Каждое окружение не что иное как область видимости локальных переменных. Окружения отдельных документов не пересекаются и соответственно вы не можете использовать в одном документе вспомогательные функции, определённые в другом документе.


Для удобства управления окружениями предоставлено несколько базовых конструкций:
1. (document:insert <идентификатор>)
В результате происходит вставка «окружения» внутрь существующего, <идентификатор> – это идентификатор документа как файла, определённый одним из перечисленных выше способов.


Пример:


2. (document:envelop keyword), (document:end-envelop keyword) – для создания вложенного окружения вовсе не обязательно создавать отдельные файлы, достаточно окружить его инструкциями document:envelop и document:end-envelop.
Последняя конструкция не обязательна если вы хотите распространить вложенное окружение до конца файла.


Пример:



3. (document:surround <идентификатор>) – иногда бывает полезно добавить не вложенное окружение, а наоборот, охватить данный документ каким-то окружением из другого файла.


Пример:


О том какие бывают окружения мы познакомимся в следующем разделе

3. Документ как виджет


У любого виджета есть атрибуты: текст у кнопки, длина у списка.
Чтобы с атрибутами можно было работать – их надо создать. Для этого существует стандартное окружение with-attributes.
В качестве дополнительных параметров в инструкцию document:envelop передаётся список имён атрибутов, которые мы хотим определить.


Пример:


Информация об этих атрибутах сообщается графическому представлению виджета после того как он будет создан, то есть это есть не что иное как рычаги управления графическим представлением виджета.


Однако некоторые параметры надо знать прямо при создании представления, как минимум надо знать тип создаваемого представления (кнопка или список), а также родительский виджет, в который нужно вставить данный.


Поэтому существует особая разновидность атрибутов – атрибуты инициализации, которые создаются в окружении
with-init-attributes.


Пример:


В alterator существует заранеее подготовленный документ со списком распространённых атрибутов – /std/attributes, который можно включать в качестве охватывающего окружения.


Пример:


После того как атрибуты созданы, их можно задавать. Принцип простой:
«имя значение» или "(имя значение значение)"


Пример:


На самом деле во втором случае скобки можно опустить ибо атрибут layout-policy знает, что ему требуется обязательно не одно, а два значения, атрибуту сообщается количество обязательных аргументов прямо при его создании.
Вместо простого указания имени, имя и количество параметров заключаются в круглые скобки



Поэтому предыдущий пример можно переписать следующим образом



Вообще общее правило такое, скобки вокруг атрибутов стоит употреблять только для повышения читаемости или для передачи аргументов в количестве большем чем обязательное:



Примитивным виджетам – примитивные документы. Так для того чтобы создать кнопку – достаточно документа, в котором будет указан её тип:


Аналогично и для списков, меню, и прочих компонент стандартного конструктора GUI.


А как же из готовых примитивов строить сложные виджеты? Переходим на следующий уровень игры:

4. Документ как контейнер


Каждый виджет ни что иное как контейнер свойств: атрибутов, callback'ов и других вложенных виджетов.
Каждый контейнер имеет минимум два предопределённых атрибута: тип ( со значением по-умолчанию “root”) и указатель на родительский контейнер. Те самые type и parent.


Чтобы отличать вложенные окружения от полноценных виджетов, которые вставляются в данный существует особая конструкция – (document:subdocument <идентификатор>).


Пример:


Если мы хотим удобно использовать какой-либо документ, его стоит оформить как контейнер.
Делается это при помощи окружения with-container-presentations.
В качестве параметров перечисляются:
1. Имя контейнера, которым будем в дальнейшем пользоваться
2. Идентификатор документа, в котором содержится описание контейнера.
3. атрибуты по-умолчанию.


Первый параметр – имя функции на языке scheme, которая будет обеспечивать удобную работу с виджетом, а третий – небольшое упрощение жизни. Например, кнопка всегда создаётся с каким-то текстом, поэтому гораздо удобнее писать
(button “some-name”) вместо (button text “some-name”)


Пример:

В результате получаем документ заданной ширины и высоты с вставленными в него кнопкой и меткой.
Существует документ с предопределёнными традиционными атрибутами и контейнерами – «/std/base». Поэтому предыдущий пример сокращается до:


Имея вспомогательные функции для работы с контейнерами можно объединять целлые россыпи виджетов:


Как вы должно быть заметили каждый виджет (точнее его контейнерная фунция) принимает атрибуты по тому же принципу, что и основной документ, через пробел следуют серии «имя значение».

5. Документ как совокупность виджетов


В реальной практике требуется ещё уметь передавать атрибутам функции – обработчики событий (callbacks), а также уметь именовать виджеты, чтобы к ним можно было потом обратиться.


Именование происходит с помощью конструкции (document:id <имя> <виджет>) .

В этом примере my-button становится синонимом конкретной контейнерной функции и все обращения к ней буду равносильны обращениям к конкретному виджету


Обработчики событий – тоже атрибуты, только их значение задаётся специальным образом, а именно с помощью фунции make-callback.

Для более удобной работы существует специальная конструкция when. Предыдущая конструкция равносильна:


Уж коли можно писать обработчики событий, то неплохо бы было иметь возможность получать текущие значения атрибутов, а также вызывать обработчики событий других виджетов.


Всё очень просто, если контейнерной функции передаётся атрибут с количеством аргументов меньше обязательного (чаще всего без аргументов), то это воспринимается как желание получить атрибуты.
Если в процессе получения атрибута выясняется, что это обработчик (callback), то он немедленно исполняется.


Вот пример диалога, когда из строки ввода считывается её содержимое и передаётся в метку


В следующих разделах будут рассмотрены уже более сложные техники работы с документами, вполне возможно что для работы вам они и не потребуются.

6. Документ как совокупность компонент


В контейнере содержатся как правило только базовые атрибуты и для проведения более сложных модификаций приходится:

  1. вытащить атрибут
  2. изменить атрибут
  3. сохранить атрибут

Это не удобно, поэтому есть атрибуты второго уровня: они перехватывают запрос на изменение (или получение) данных и проводят соответствующие модификации примитивных атрибутов. Вот несколько примеров подобных аттрибутов:

  1. count у listbox – получает все строки (атрибут rows) и подсчитывает их количество
  2. append-text у textbox – получает предыдущее значение текста, добавляет к нему новый и сохраняет результат.

Все аттрибуты второго уровня создаются при помощи окружения with-meta-attributes.
Пример:


Для каждого аттрибута определяется

  1. имя 
  2. методы которые будут вызваны в случае запросов на получение (meta-get) и изменение (meta-set)

Каждому методу передаются два параметра: он сам (self) и виджет к которому он принадлежит (widget).
Также предоставляются вспомогательные функции value-of для выяснения своего содержимого и simple-get, для запросов к атрибутам первого уровня.


Работа с мета-аттрибутами уже более сложная, требует более глубоких познаний в alterator, поэтому подробно рассматриваться не будет, желающие могут посмотреть предопределённые мета-аттрибуты в файле «/std/meta-atributes», который также как и «/std/attributes» автоматически подгружается из «/std/base».


Ну и наконец высший пилотаж – если есть мета-аттрибуты, то должны быть и мета-виджеты.
Возможно вы сделали какой-то хороший виджет и решили использовать его повторно в других проектах. Причём оформить его так, чтобы пользователи и не догадались, что это именно комбинированный виджет, а не примитивный. Такая возможность есть.
Что виджет, что контейнер – всё едино. Не хватает только аттрибутов.


Существует ещё один тип аттрибутов – прокси-аттрибуты. Их задача – перехватывать запросы на получение/изменение значения и вызывать ваши фунции внутри виджета. Например, вы сделали специальный виджет для смены пароля.
Пользователь запрашивает у вашего виджета password1, этот запрос перехватывается и вызывается функция внутри вашего виджета, которая возращает содержимое определённого edit.


Итак, стало быть мета-виджет – это обычный документ, в котором дополнительно определены виртуальные прокси аттрибуты. Последние создаются с помощью окружения with-proxy-attributes.
А вот и пример с паролями:


Если вы захотите где-то поработать с этим виджетом, то надо всего-лишь до-определить недостающие атрибуты (именно обычные атрибуты, чтобы контейнер понял с какой стороны к нему обращаются) и всё ... дальше работать как обычно.

7. Переходы между документами

Доступны следующие команды для перехода между разными виджетами:


 
Файлов нет. [Показать файлы/форму]
Комментарии [Скрыть комментарии/форму]

Касательно layout-policy:

-- MichaelShigorin (2006-10-02 16:55:39)