Ada_Ru форум

Vladyslav Kozlovskyy wrote:

>

> Я пока вижу такие его части (которые мы пытаемся свести вместе):

>

> I. Есть данные приложения в терминах приложения;

> II. Есть проекция данных на GUI форму в терминах GUI;

> III. Есть некий промежуточный уровень (Ёнтерфейс?) между I и II;

> IV. Есть некий монитор (машина состояний?) следящий/управляющий GUI

> формой (enable/disable елементов формы, контроль вводимых

> пользователем данных, подсказки пользователю, динамическое изменение

> GUI формы и т.д.) Его цель - непротиворечивые и неделимые данные.

>

Я бы на первом этапе разделил немного по другому:

 

I. Есть реализация ядра приложения, со своими данными и подпрограммами;

II. Есть реализация UI (не обязательно GUI) со всей своей навесухой;

III. Есть спецификация интерфейса между ними.

 

Это вид с точки зрения структуры конечного приложения.

 

И есть вид с точки зрения реализации UI:

 

I. Иерархия виджетов;

II. Подпрограммы обратного вызова;

III. Реализация компонентов, объявленных в спецификации.

 

И, последнее, есть набор типовых задач и мастеров для их решения в рамках каждого из поддерживаемых toolkit-ов:

 

I. Иерархические меню;

II. Машины состояний форм;

III. Интернационализация;

IV. Визуальное проектирование внешнего вида.

 

 

> Я вижу такой порядок работы подобного паттерна:

> 1. Создание GUI форм(ы)

> 2. Цикл:

> а. Инициализация форм(ы) исходными данными;

> б. GUI-транзакция взаимодействия с пользователем. Цель транзакции

> - получить непротиворечивые данные на выходе интерфейса;

> в. получение новых данных из форм(ы) в программу;

> г. в случае необходимости перейти к п.а, иначе завершить цикл (п.3)

> 3. Уничтожение GUI форм(ы)

>

Имею одно важное замечание. Для расширения сферы возможного применения интерфейс между ядром приложения и UI не должен предполагать использования подобных циклов. Интерфейс вводит только "сообщения" между ядром приложения и UI. Всё остальное ложится целиком и полностью на плечи UI - ему виднее как и какую стратегию использовать с данной сменной панелькой.

 

> Судя по обсуждениям сейчас обсуждается только вопрос II и, частично, III.

> Тогда, как для действительно полного интерактивного взаимодействия с

> пользователем надо, на мой взгляд больше внимания обратить на вопрос IV.

>

Согласен с обоими утверждениями. Дело тут в том, что если решить вопрос с описание "границы", то вопрос IV переходит во внутреннюю область UI и его можно (нужно!!!) рассмотреть подробнее уже после.

 

> На мой взгляд для реализации монитора в этом паттерне не вредно

> обратить внимание на такие особенности Ады, как защищенные типы и

> задачи.

>

Это не есть хорошее решение:

 

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

 

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

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

On Mon, 15 Aug 2005 13:41:36 +0400, Vadim Godunko <godunko@...> wrote:

 

На мой взгляд для реализации монитора в этом паттерне не вредно

> обратить внимание на такие особенности Ады, как защищенные типы и

> задачи.

>

Это не есть хорошее решение:

- UI взаимодействия с пользователем редко предполагают использование

нескольких нитей. Даже при их использовании обработка ввода (этот

монитор) производится отдельной нитью, а вспомогательные только

отрисовывают данные. Т.е. эти сегменты (обычно) никогда друг с другом не

пересекаются, следовательно использовать конструкции параллельного

программирования не требуется.

- прикладная задача может накладывать серьёзные ограничения на

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

допускать их использования.

 

Боюсь что ограничиться чем-то одним не получиться - тоесть придется

поддерживать оба варианта работы UI - и как вызываемой процедуры

в одном процессе с программой, так и в виде параллельной задачи.

 

Это будет зависеть от типа приложения. Например, для обычной

рассчетной программы это вызов продуры(типа "введите такое-то значение"),

а для интерактивных программ вроде CAD или редакторов это процесс,

причем который еще и может сам запускать параллельные процессы.

(например, запустить какой-то постпроцессор из гуя пока другой

модуль что-то считает независимо и может даже и не знать что такой есть)

 

Для простой рассчетной задачи нафиг не надо заморачиваться

с написанием каких-то процедур обратного вызова и тп, а для

других это надо(например, гуй самой операционной системы)

как одна из основных функций(запуск программ из гуя ОС например)

 

Vladimir

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/