Доброе утрое!
Хочу продолжить разговор о UI.
Следуя идее отделения логики от внешнего вида предлогаю использовать два различных файла: файл описания интерфейса и файл описания реализации.
Файл описания интерфейс удобно было бы сделать в Ada-like стиле. Напротив, описание реализации вполне можно сотворить в XML.
Описание интерфейса должно включать:
- компоненты (окна верхнего уровня, диалоги и т.д.)
- атрибуты компонентов (атрибуты должны быть типизированными с привязкой к типам данных Ada кода)
- операции компонентов (то, что программа может вызвать у компонента)
- "импортируемые" подпрограммы программы (то, что может вызвать реализация интерфейса в программе)
Описание реализации должно включать:
- дерево виджетов конкретного toolkit-a
- свойства этих виджетов
- все формализованные взаимосвязи по упарвлению
- сегменты пользовательского кода
Генератор (давайте не будем использовать слово "препроцессор", оно здесь не очень уместно) принимает оба файла, проверяет, что описание интерфейса соответствует фактическому Ada коду, и генерирует код на основании описания соответствующей реализации.
Комментарии?
-- Vadim Godunko
Technoserv A/S
Rostov-on-Don, Russia
Следуя идее отделения логики от внешнего вида предлогаю использовать два различных файла: файл описания интерфейса и файл описания реализации.
можешь набросать примерчик файла описания и файла реализации. Что-то не очень ясно
Файл описания интерфейс удобно было бы сделать в Ada-like стиле. Напротив, описание реализации вполне можно сотворить в XML.
Реализация под конкретную платформу? А причем здесь XML? Почему нельзя обойтись тоже Адой?
Генератор (давайте не будем использовать слово "препроцессор"
Догласен. Есть еще одно название - precompiler (прекомпиллер) (из ESQL, помните? Есть в поставке GNADE. Прикольная штучка, использовать - супер удобно, только ее IDE-шки не поддерживают :( ) Фактически все такие генераторы (прекомпиллеры) есть нечто иное, как еще один слой front-end-а. Я вижу, как минимум, четыре такие дополнительные слоя:
прекомпиллеры
SQL/XML
COM/CORBA
PERSISTENT OBJECTS (примерная реализация см. ODB - Object
Persistency Framework for Ada 95)
GUI
Фактически они - расширители языка - добавляют native поддержку вещей, не внесенных в стандарт языка.
ODB, например так описывает persistent object:
type Object is persistent record
Name : attribute Unbounded_String;
Players : attribute Reference;
Maze : attribute Maze_Type ;
end record ;
А GNADE записывает запрос так:
declare
EXEC SQL DECLARE MyDataBase DATABASE ;
EXEC SQL BEGIN DECLARE SECTION ;
Deptno : INT
EXEC SQL END DECLARE SECTION ;
begin
EXEC SQL AT MyDataBase
SELECT DEPTNO INTO :Deptno FROM EMPLOYEES
WHERE NAME = 'Erdmann' ;
Ada.Text_IO.Put_Line( " Deptno => " & Deptno'img );
end;
Может в этом направлении копать?
--
Best regards,
Vladyslav
Vladyslav Kozlovskyy wrote:
Следуя идее отделения логики от внешнего вида предлогаю использовать два
различных файла: файл описания интерфейса и файл описания реализации.
можешь набросать примерчик файла описания и файла реализации. Что-то
не очень ясно
Попробую. :) Например так:
Описание:
with Program_Callbacks; -- модуль программы
package UI is
procedure On_Quit is in Program_Callbacks;
-- Подпрограмма, завершающая выполнение программы.
procedure On_Shutdown is in Program_Callbacks;
-- Подпрограмма, завершающая выполнение программы и выключающая компьютер. :)
interface QuitConfirmationDialog is
procedure Show;
end QuitConfirmationDialog;
end UI;
Реализация (в Ada стиле):
package implementation UI on Motif is
interface implementation QuitConfirmationDialog is
widget Dialog is new Xm_Template_Dialog with
widget Ok_Button is builtin OK_BUTTON;
widget Cancel_Button is builtin CANCEL_BUTTON;
widget Form is new Xm_Form with
widget Label is new Xm_Label_Gadget with
for Xm_N_Left_Attachemnt use Xm_Attach_Form;
for Xm_N_Right_Attachment use Xm_Attach_Form;
for Xm_N_Top_Attachment use Xm_Attach_Form;
for Xm_N_Bottom_Attachment use Xm_Attach_Widget;
for Xm_N_Bottom_Widget use Shutdown_Toggle;
end Label;
widget Shutdown_Toggle is new Xm_Toggle_Button_Gadget;
end Form;
end Dialog;
procedure Show is
begin
Xt_Manage_Child (Dialog);
end Show;
end QuitConfirmationDialog;
end UI;
-- Vadim Godunko
Technoserv A/S
Rostov-on-Don, Russia
Реализация (в Ada стиле):
package implementation UI on Motif is
interface implementation QuitConfirmationDialog is
widget Dialog is new Xm_Template_Dialog with
widget Ok_Button is builtin OK_BUTTON;
widget Cancel_Button is builtin CANCEL_BUTTON;
widget Form is new Xm_Form with
widget Label is new Xm_Label_Gadget with
for Xm_N_Left_Attachemnt use Xm_Attach_Form;
for Xm_N_Right_Attachment use Xm_Attach_Form;
for Xm_N_Top_Attachment use Xm_Attach_Form;
for Xm_N_Bottom_Attachment use Xm_Attach_Widget;
for Xm_N_Bottom_Widget use Shutdown_Toggle;
end Label;
widget Shutdown_Toggle is new Xm_Toggle_Button_Gadget;
end Form;
end Dialog;
procedure Show is
begin
Xt_Manage_Child (Dialog);
end Show;
end QuitConfirmationDialog;
end UI;
Я так полагаю, реализация под конкретную платформу должна генерится автоматически?
--
Best regards,
Vladyslav
Vladyslav Kozlovskyy wrote:
Реализация (в Ada стиле):
package implementation UI on Motif is
^^^^
Это есть указание toolkit-а
interface implementation QuitConfirmationDialog is
widget Dialog is new Xm_Template_Dialog with
widget Ok_Button is builtin OK_BUTTON;
widget Cancel_Button is builtin CANCEL_BUTTON;
widget Form is new Xm_Form with
widget Label is new Xm_Label_Gadget with
for Xm_N_Left_Attachemnt use Xm_Attach_Form;
for Xm_N_Right_Attachment use Xm_Attach_Form;
for Xm_N_Top_Attachment use Xm_Attach_Form;
for Xm_N_Bottom_Attachment use Xm_Attach_Widget;
for Xm_N_Bottom_Widget use Shutdown_Toggle;
end Label;
widget Shutdown_Toggle is new Xm_Toggle_Button_Gadget;
end Form;
end Dialog;
procedure Show is
begin
Xt_Manage_Child (Dialog);
end Show;
end QuitConfirmationDialog;
end UI;
Я так полагаю, реализация под конкретную платформу должна генерится автоматически?
Да.
-- Vadim Godunko
Technoserv A/S
Rostov-on-Don, Russia
Vladyslav Kozlovskyy wrote:
>Реализация (в Ada стиле):
>package implementation UI on Motif is
^^^^
Это есть указание toolkit-а
interface implementation QuitConfirmationDialog is
widget Dialog is new Xm_Template_Dialog with
widget Ok_Button is builtin OK_BUTTON;
widget Cancel_Button is builtin CANCEL_BUTTON;
widget Form is new Xm_Form with
widget Label is new Xm_Label_Gadget with
for Xm_N_Left_Attachemnt use Xm_Attach_Form;
for Xm_N_Right_Attachment use Xm_Attach_Form;
for Xm_N_Top_Attachment use Xm_Attach_Form;
for Xm_N_Bottom_Attachment use Xm_Attach_Widget;
for Xm_N_Bottom_Widget use Shutdown_Toggle;
end Label;
widget Shutdown_Toggle is new Xm_Toggle_Button_Gadget;
end Form;
end Dialog;
procedure Show is
begin
Xt_Manage_Child (Dialog);
end Show;
end QuitConfirmationDialog;
>end UI;
Я так полагаю, реализация под конкретную платформу должна генерится автоматически?
Да.
И из чего эта реализация должна генерится? Я ничего подобного в
описании не видел (кнопки, лабелки и т.д.) что-то я не доганяю :(
--
Best regards,
Vladyslav
Vladyslav Kozlovskyy wrote:
interface implementation QuitConfirmationDialog is
Начало описания иерархии и свойств
widget Dialog is new Xm_Template_Dialog with
widget Ok_Button is builtin OK_BUTTON;
widget Cancel_Button is builtin CANCEL_BUTTON;
widget Form is new Xm_Form with
widget Label is new Xm_Label_Gadget with
for Xm_N_Left_Attachemnt use Xm_Attach_Form;
for Xm_N_Right_Attachment use Xm_Attach_Form;
for Xm_N_Top_Attachment use Xm_Attach_Form;
for Xm_N_Bottom_Attachment use Xm_Attach_Widget;
for Xm_N_Bottom_Widget use Shutdown_Toggle;
end Label;
widget Shutdown_Toggle is new Xm_Toggle_Button_Gadget;
end Form;
end Dialog;
Конец описания иерархии и свойств
> И из чего эта реализация должна генерится? Я ничего подобного в
описании не видел (кнопки, лабелки и т.д.) что-то я не доганяю :(
Конструкция вида widget <имя> is new <базовый тип виджета> и есть описание иерархии:
<widget> ::=
widget <identifer> is new <widget_class_identifier> with
<children_or_properties>
end <identifier>;
<chidren_or_property> ::= <children>* | <property>*
<children> ::= <widget>
<property> ::= for <property_identifier> use <value>
-- Vadim Godunko
Technoserv A/S
Rostov-on-Don, Russia
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
Vladyslav Kozlovskyy wrote:
И из чего эта реализация должна генерится? Я ничего подобного в
описании не видел (кнопки, лабелки и т.д.) что-то я не доганяю :(
Помему я не понял вопроса. :(
Описание UI состоит из двух частей: описание интерфейса и описание реализации.
описание интерфейса (первый пример) - общее для всех реализаций.
описание реализации (второй пример) - необходимая и достаточная информаци об обустройстве UI для генератора кода.
В описании интерфейса конпки, метки и пр. не фигурируют, они описываю только интерфейс между приложением и UI, в описании реализации они как раз и присутствуют, поскольку именно на основании этого описание будет сгенерирован код и все вспомогательные файлы (например, ресурсы X).
-- Vadim Godunko
Technoserv A/S
Rostov-on-Don, Russia
Описание UI состоит из двух частей: описание интерфейса и описание реализации.
описание интерфейса (первый пример) - общее для всех реализаций.
описание реализации (второй пример) - необходимая и достаточная информаци об обустройстве UI для генератора кода.
В описании интерфейса конпки, метки и пр. не фигурируют, они описываю только интерфейс между приложением и UI, в описании реализации они как раз и присутствуют, поскольку именно на основании этого описание будет сгенерирован код и все вспомогательные файлы (например, ресурсы X).
Слишком сложно. Если я не знаю Иксов и пишу под Win32, кто напишет Motif-based часть моей программы? А как же переносимость?
А очень надеялся на хорошего дядечку (прекомпилятор), который сделает это за меня. А посему на вход я хочу подать нечто кросс-платформенное, не зависящее от платформы.
Может моя программа должна вообще работать на символьных терминалах. А че - в символьном режиме можно представить почти все, кроме рисунков (иконок) и rich
text (и то, подчеркивание и цвет там могут иметь место). Я раньше пробовал - прикольно получается :)
Мне больше такой подход:
Я рисую/пишу GUI (формочки, кнопочки и т.д.)
Я подцепляю к ним нужные мне функции (калбеки)
Я выбираю платформу
и нажимаю кнопку "Готово!" :)
А реализацию (например такую, как ты описал для Motif) пускай за меня кто-то другой напишет :)
--
Best regards,
Vladyslav
Vladyslav Kozlovskyy wrote:
Описание UI состоит из двух частей: описание интерфейса и описание
реализации.
описание интерфейса (первый пример) - общее для всех реализаций.
описание реализации (второй пример) - необходимая и достаточная информаци об обустройстве UI для генератора кода.
В описании интерфейса конпки, метки и пр. не фигурируют, они описываю только интерфейс между приложением и UI, в описании реализации они как раз и присутствуют, поскольку именно на основании этого описание будет сгенерирован код и все вспомогательные файлы (например, ресурсы X).
Слишком сложно. Если я не знаю Иксов и пишу под Win32, кто напишет
Motif-based часть моей программы? А как же переносимость?
Часть реализации не переносится на другую платформу. Для каждой платформы нужно самостоятельно писать собственную реализацию интерфейса.
Задача разработки интерфейса конкретной платформы должна выполняться в основном builder-ом.
А очень надеялся на хорошего дядечку (прекомпилятор), который сделает
это за меня. А посему на вход я хочу подать нечто кросс-платформенное,
не зависящее от платформы.
Все имеющиеся подобные реализации не лишены недостатков. Речь как раз идёт об отказе от подобной практики.
Однако, в последующем, вполне можно сделать конверторы их реализации одной платформы в реализацию для другой платформы.
Может моя программа должна вообще работать на символьных терминалах. А
че - в символьном режиме можно представить почти все, кроме рисунков (иконок) и rich
text (и то, подчеркивание и цвет там могут иметь место). Я раньше пробовал -
прикольно получается :)
Так подставляй собственный интерфейс на основе NCurses и вперёд!
PS. А что, может NCurses тоже добавим в список планируемых поддерживаемых платформ?
Мне больше такой подход:
Я рисую/пишу GUI (формочки, кнопочки и т.д.)
Не спорю.
Я подцепляю к ним нужные мне функции (калбеки)
Не совсем callback-и. Ты имеешь возможность вызывать все импортированные в спецификации интерфейса Ada подпрограммы. Соответствующий мастер позволит тебе сформировать параметры на основе значений полей, выражений, ещё чего-либо).
Я выбираю платформу
и нажимаю кнопку "Готово!" :)
А реализацию (например такую, как ты описал для Motif) пускай за меня
кто-то другой напишет :)
Эээх... Если-бы так можно было! :(
-- Vadim Godunko
Technoserv A/S
Rostov-on-Don, Russia
Задача разработки интерфейса конкретной платформы должна выполняться в основном builder-ом.
Который и сохраняет разработтаный интерфейс в своем унифицированном формате (xml?)
Зачем тогда отдельный язык для реализации?
Почему бы тогда билдеру и не генерить оптимальный код на чистой аде под конкретную платформу. КОНКРЕТНЫЙ билдер должен это уметь?
А очень надеялся на хорошего дядечку (прекомпилятор), который сделает это за меня. А посему на вход я хочу подать нечто кросс-платформенное, не зависящее от платформы.
Все имеющиеся подобные реализации не лишены недостатков. Речь как раз идЈт об отказе от подобной практики.
Но все же должно же быть и что-то общее. Иначе и портировать то ничего не удастся. Базовые понятия, принципы должны быть общими у всего
семейства билдеров.
Однако, в последующем, вполне можно сделать конверторы их реализации одной платформы в реализацию для другой платформы.
Может моя программа должна вообще работать на символьных терминалах. А че - в символьном режиме можно представить почти все, кроме рисунков (иконок) и rich
text (и то, подчеркивание и цвет там могут иметь место). Я раньше пробовал - прикольно получается :)
Так подставляй собственный интерфейс на основе NCurses и вперЈд!
Уже пробовал :)
PS. А что, может NCurses тоже добавим в список планируемых
поддерживаемых платформ?
Обязательно. Без этого никак :)
Мне больше такой подход:
Я рисую/пишу GUI (формочки, кнопочки и т.д.)
Не спорю.
Я подцепляю к ним нужные мне функции (калбеки)
Не совсем callback-и. Ты имеешь возможность вызывать все импортированные в спецификации интерфейса Ada подпрограммы. Соответствующий мастер позволит тебе сформировать параметры на основе значений полей,
выражений, ещЈ чего-либо).
Типа Ада-скрипта?
Я выбираю платформу
и нажимаю кнопку "Готово!" :)
А реализацию (например такую, как ты описал для Motif) пускай за меня кто-то другой напишет :)
Эээх... Если-бы так можно было! :(
--
Vadim Godunko
Technoserv A/S
Rostov-on-Don, Russia
--------------------------------------------------------------------------------
YAHOO! GROUPS LINKS
Visit your group "ada_ru" on the web.
To unsubscribe from this group, send an email to:
ada_ru-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
--------------------------------------------------------------------------------
--
Best regards,
Vladyslav
--- In ada_ru@yahoogroups.com, Vadim Godunko <godunko@s...> wrote:
ÄÐÙÛ ÞßØáÐÝØï ØÝâÕàäÕÙá ãÔÞÑÝÞ ÑëÛÞ Ñë áÔÕÛÐâì Ò Ada-like áâØÛÕ.
° ÒÞâ ÕáÛØ ÕÓÞ ãÔÐáâáï áÔÕÛÐâì Ò çØáâÞÙ °ÔÕ,
âÞ ÜÞÖÝÞ ÒÞáßÞÛì×ÞÒÐâìáï ASIS-ÞÜ ÔÛï ÕÓÞ ÐÝÐÛØ×Ð Ø
ÝÕ ßØáÐâì áØÝâÐÚáØçÕáÚØÙ ÐÝÐÛØ×ÐâÞà áÐÜÞÜã.
½ÐßàÞâØÒ, ÞßØáÐÝØÕ àÕÐÛØ×ÐæØØ ÒßÞÛÝÕ ÜÞÖÝÞ áÞâÒÞàØâì Ò XML.
¾ßØáÐÝØÕ ØÝâÕàäÕÙáÐ ÔÞÛÖÝÞ ÒÚÛîçÐâì:
- ÚÞÜßÞÝÕÝâë (ÞÚÝÐ ÒÕàåÝÕÓÞ ãàÞÒÝï, ÔØÐÛÞÓØ Ø â.Ô.)
Ï×ëÚ ÞßØáÐÝØï ØÝâÕàäÕÙáÐ ÑãÔÕâ ÞÓÞÒÐàØÒÐâì
ÒÞ×ÜÞÖÝëÕ ÒÐàØÐÝâë ÚÞÜßÞÝÕÝâ? ÇâÞ âãÔÐ ÕéÕ ßÞßÐÔÕâ
ÚàÞÜÕ ÞÚÞÝ Ø ÔØÐÛÞÓÞÒ? ºÞÜßÞÝÕÝâë ÒÒÞÔÐ ×ÝÐçÕÝØÙ?
³àØÔë? ´ÐÒÐÙâÕ ÝÐÑàÐáÐÕÜ áßØáÞçÕÚ, ßÞâÞÜ ÑÕÔãÜ àÐáèØàïâì,
ÕáÛØ ßÞÝÐÔÞÑØâáï.
- ÐâàØÑãâë ÚÞÜßÞÝÕÝâÞÒ (ÐâàØÑãâë ÔÞÛÖÝë Ñëâì âØßØ×ØàÞÒÐÝÝëÜØ á
ßàØÒï×ÚÞÙ
Ú âØßÐÜ ÔÐÝÝëå Ada ÚÞÔÐ)
Ï×ëÚ ÞßØáÐÝØï ØÝâÕàäÕÙáÐ ÑãÔÕâ ÞÓÞÒÐàØÒÐâì
ÒÞ×ÜÞÖÝëÕ ÐâàØÑãâë ÔÛï ÚÐÖÔÞÓÞ ÒØÔÐ ÚÞÜßÞÝÕÝâ?
- ÞßÕàÐæØØ ÚÞÜßÞÝÕÝâÞÒ (âÞ, çâÞ ßàÞÓàÐÜÜÐ ÜÞÖÕâ Òë×ÒÐâì ã ÚÞÜßÞÝÕÝâÐ)
ÍâÞ ÚÐÚ-âÞ ßÕàÕÚÛØÚÐÕâáï á ßàÕÔØÔãéØÜ ßãÝÚâÞÜ,
ÝÐÒÕàÝïÚÐÚ çâÞÑ ãáâÐÝÞÒØâì ÚÐÚÞÙ-âÞ ÐââàØÑãâ
ÝãÖÝÞ Òë×ÒÐâì ÚÐÚãî-âÞ ÞßÕàÐæØî...
- "ØÜßÞàâØàãÕÜëÕ" ßÞÔßàÞÓàÐÜÜë ßàÞÓàÐÜÜë (âÞ, çâÞ ÜÞÖÕâ Òë×ÒÐâì àÕÐÛØ×ÐæØï ØÝâÕàäÕÙáÐ Ò ßàÞÓàÐÜÜÕ)
ÁßØáÞÚ áÞÑëâØÙ, Ú ÚÞâÞàëÜ ÜÞÖÝÞ ßàÕÔÞáâÐÒÛïâì ßÞÔßàÞÓàÐÜÜë
âÞÖÕ ÑãÔÕâ ÞßàÕÔÕÛïâáï Ò ï×ëÚÕ ÞßØáÐÝØï ØÝâÕàäÕÙáÐ?
¸ÛØ Ú çÕÜã ÚàÕßØâáï ßÞÔßàÞÓàÐÜÜÐ - íâÞ Ò àÕÐÛØ×ÐæØØ?
¾ßØáÐÝØÕ àÕÐÛØ×ÐæØØ ÔÞÛÖÝÞ ÒÚÛîçÐâì:
- ÔÕàÕÒÞ ÒØÔÖÕâÞÒ ÚÞÝÚàÕâÝÞÓÞ toolkit-a
- áÒÞÙáâÒÐ íâØå ÒØÔÖÕâÞÒ
- ÒáÕ äÞàÜÐÛØ×ÞÒÐÝÝëÕ Ò×ÐØÜÞáÒï×Ø ßÞ ãßÐàÒÛÕÝØî
- áÕÓÜÕÝâë ßÞÛì×ÞÒÐâÕÛìáÚÞÓÞ ÚÞÔÐ
¼ÞÖÕâ ÚàÞÜÕ áÕÓÜÕÝâÞÒ ÚÞÔÐ ßàÕÔãáÜÞâàÕâì ÕéÕ ÚÐÚÞÙ-âÞ
ßáÕÒÔÞÚÞÔ ÔÛï ÜÐÝØßãÛØàÞÒÐÝØï áÞ áÒÞÙáâÒÐÜØ ÒØÔÖÕâÞÒ?
´Ûï âÞÓÞ çâÞÑë ÕáÛØ ã àÐ×Ýëå àÕÐÛØ×ÐæØÙ Õáâì ÒØÔÖÕâë
á ÞÔØÝÐÚÞÒëÜØ áÒÞÙáâÒÐÜØ, âÞ íâÞâ ßáÕÒÔÞ ÚÞÔ ßÕàÕÝÕáÕâáï
Ø× ÞÔÝÞÙ àÕÐÛØ×ÐæØØ Ò ÔàãÓãî ÑÕ× Ø×ÜÕÝÕÝØÙ. ÂØßÐ
"ÕáÛØ î×Õà ÝÐÖÐÛ ÚÝÞßÚã Clear" ßáÕÒÔÞÚÞÔ =>
²ØÔÖÕâ Input_Text áÒÞÙáâÒÞ Text = "".
ÀÕÐÛØ×ÞÒÐâì âÞÛìÚÞ ÚÞßØàÞÒÐÝØÕ/ãáâÐÝÞÒÚã áÒÞÙáâÒ Ø
ÜÞÖÕâ ÕéÕ ãáÛÞÒÝëÕ ÞßÕàÐæØØ ÝÐ ÞáÝÞÒÕ ×ÝÐçÕÝØï áÒÞÙáâÒ.
ºÞÜÜÕÝâÐàØØ?
µéÕ âÐÚÞÙ ÒÞßàÞá. ½ãÖÝÞ ÝÐÜ ÞßØáÐÝØï âÞÛìÚÞ ÚÞÝÚàÕâÝëå íÛÕÜÕÝâÞÒ, ØÛØ ßÞÝÐÔÞÑïâáï ÕéÕ "âØßë" íÛÕÜÕÝâÞÒ, ÔÛï ßÞáÛÕÔãîéÕÓÞ
áÞ×ÔÐÝØï ÝÕáÚÞÛìÚØå íÚ×ÕÜßÛïàÞÒ ÞÔÝÞÓÞ âØßÐ. ½ÐßàØÜÕà
¾ßØáëÒÐÕèì ÞÚÝÞ ßàÞáÜÞâàÐ ÔÞÚãÜÕÝâÐ, Ð ßÞâÞÜ î×Õà Øå
ÞâÚàëÒÐÕâ áâÞÛìÚÞ, áÚÞÛìÚÞ ÝãÖÝÞ Ø Øå Ò ßàÞÓàÐÜÜÕ ÞÔÝÞÒàÕÜÕÝÝÞ
áãéÕáâÒãÕâ N-Õ ÚÞÛ-ÒÞ. °ÝÐÛÞÓØçÝÞ ßÛÐÔïâáï, áÚÐÖÕÜ
áâàÐÝØçÚØ(ÒÚÛÐÔÚØ) Ò ÞÚÝÕ, ØÛØ ßãÝÚâë ÜÕÝî Ò ÜÕÝî
"ÞâÚàëàëÕ ÞÚÝÐ".
--
Vadim Godunko
--
Maxim Reznik
Vladyslav Kozlovskyy wrote:
Задача разработки интерфейса конкретной платформы должна выполняться в
основном builder-ом.
Который и сохраняет разработтаный интерфейс в своем унифицированном формате (xml?)
XML или Ada подобный - предстоит обсудить. На Ada-подобном легче было пример привести :)
Зачем тогда отдельный язык для реализации?
Как формат данных, сохраняемых builder-ом. (его нужно иметь возможность отдельно компилировать, без запуска builder-а)
Почему бы тогда билдеру и не генерить оптимальный код на чистой аде
под конкретную платформу. КОНКРЕТНЫЙ билдер должен это уметь?
Да, используя соответствующие модули компилятора.
Но все же должно же быть и что-то общее. Иначе и портировать то ничего
не удастся. Базовые понятия, принципы должны быть общими у всего
семейства билдеров.
Базовыми понятиями как раз и будут импортируемые (из программы в интерфейс) подпрограммы, типы данных, подпрограммы интерфейсов.
Ясное дело, что большинство графических toolkit-ов построены так или иначе, но схоже. И портировать из Motif в Windows вполне возможно. А как портировать из Windows в HTML? Или из Gtk в NCurses? По ходу реализации и эксплуатации проекта я думаю мы сами найдём ответы на вопросы автоматизации протирования. :)
PS. А что, может NCurses тоже добавим в список планируемых поддерживаемых платформ?
Обязательно. Без этого никак :)
Добавил.
Я подцепляю к ним нужные мне функции (калбеки)
Не совсем callback-и. Ты имеешь возможность вызывать все импортированные в спецификации интерфейса Ada подпрограммы. Соответствующий мастер позволит тебе сформировать параметры на основе значений полей, выражений, ещ Јчег-олиб).
оТип аАд-аскрипт?
аВозможн. (о.Т. едл яначал абыл об ынеплох)
-- Vadim Godunko
Technoserv A/S
Rostov-on-Don, Russia
reznikmm wrote:
--- In ada_ru@yahoogroups.com, Vadim Godunko <godunko@s...> wrote:
Файл описания интерфейс удобно было бы сделать в Ada-like стиле.
А вот если его удастся сделать в чистой Аде, то можно воспользоваться ASIS-ом для его анализа и
не писать синтаксический анализатор самому.
Возможно... Но надо подумать...
Напротив, описание реализации вполне можно сотворить в XML.
Описание интерфейса должно включать:
- компоненты (окна верхнего уровня, диалоги и т.д.)
Язык описания интерфейса будет оговаривать
возможные варианты компонент? Что туда еще попадет
кроме окон и диалогов? Компоненты ввода значений?
Гриды? Давайте набрасаем списочек, потом бедум расширять,
если понадобится.
Я бы предпочёл максимально отойти от пректики и использовать только понятие "компонент". А что он из себя представляет (окно, диалог, просто текстовое поле, непросто текстовое поле) - оставить на откуп реализации.
Язык описания интерфейса будет оговаривать
возможные атрибуты для каждого вида компонент?
Нет. Язык только описывает интерфейс между программой и UI. Т.е. импортированные из программы в UI типы данных, подпрограммы; и экспортируемые из UI в программу реализации компонентов.
Список событий, к которым можно предоставлять подпрограммы
тоже будет определятся в языке описания интерфейса?
В описании реализации. События - свойства виджетов, но не компонентов.
Или к чему крепится подпрограмма - это в реализации?
Угу.
Может кроме сегментов кода предусмотреть еще какой-то
псевдокод для манипулирования со свойствами виджетов?
Придётся.
Для того чтобы если у разных реализаций есть виджеты
с одинаковыми свойствами, то этот псевдо код перенесется
из одной реализации в другую без изменений. Типа
"если юзер нажал кнопку Clear" псевдокод =>
Виджет Input_Text свойство Text = "".
Реализовать только копирование/установку свойств и
может еще условные операции на основе значения свойств.
Мне кажется, что этот язык родится самостоятельно. :)
Еще такой вопрос. Нужно нам описания только конкретных элементов,
или понадобятся еще "типы" элементов, для последующего
создания нескольких экземпляров одного типа. Например
Описываешь окно просмотра документа, а потом юзер их
открывает столько, сколько нужно и их в программе одновременно
существует N-е кол-во. Аналогично пладятся, скажем странички(вкладки) в окне, или пункты меню в меню
"открырые окна".
Я думаю, что компонент будет всегда эквивалентен классу. Т.е. можно создать столько его экземпляров, сколько хочется программе.
-- Vadim Godunko
Technoserv A/S
Rostov-on-Don, Russia
On Wed, Aug 03, 2005 at 04:57:36PM +0400, Vadim Godunko wrote:
reznikmm wrote:
--- In ada_ru@yahoogroups.com, Vadim Godunko <godunko@s...> wrote:
>Файл описания интерфейс удобно было бы сделать в Ada-like стиле.
А вот если его удастся сделать в чистой Аде,
то можно воспользоваться ASIS-ом для его анализа и
не писать синтаксический анализатор самому.
Возможно... Но надо подумать...
Может быть типа такого:
- файл описания интерфейса - это пакет на Аде.
- для каждого компонента верхнего уровня
(у кого нет предка/контейнера: окна/диалоги)
создается вложенный пакет.
- если можно иметь много экземпляров окна/диалога
то в пакете тип и операции к нему, если нет,
то просто операции в пакете.
- доступ к (видимым) вложенным компонентам
через функции типа или пакета.
- колбеки через формальные параметры
настраиваемых пакетов.
with Ada.Calendar;
with User_Types;
package My_UI is
generic
with procedure Commit;
with procedure Rollback;
package Input_Dialog is
-- Типа нет - значит диолог м.б. только один
-- implicit compoment Sale_Time
function Get_Sale_Time return Ada.Calendar.Time;
procedure Set_Sale_Time (Data : Ada.Calendar.Time);
-- implicit component Amount
function Get_Amount return Used_Types.Amount;
procedure Set_Amount (Data : Used_Types.Amount);
procedure Show;
end Input_Dialog;
end My_UI;
Типы, описанные в пакете (соответствующие компонентам)
можно сделать неограниченными, лимитированными дабы
запретить создание и присваивание вне пакета My_UI
package Input_Dialogs is
type Input_Dialog (<>) is limited private;
procedure Create_Dialog;
function Cound_Dialog return Natural;
function Get_Dialog (Index : Positive) return Input_Dialog;
procedure Free_Dialog (Index : Positive);
end;
declare
Dlg : Input_Dialog renames Get_Dialog (I);
Amt : Amount;
begin
Show (Dlg);
Amt := Amount (Dlg);
Free_Dialog (I);
return Amt;
end;
--
Maxim Reznik
Maxim Reznik wrote:
Может быть типа такого:
- файл описания интерфейса - это пакет на Аде.
Необычно для моего личного представления, но вполне разумно.
- для каждого компонента верхнего уровня
(у кого нет предка/контейнера: окна/диалоги)
создается вложенный пакет.
Ок
- если можно иметь много экземпляров окна/диалога
то в пакете тип и операции к нему, если нет,
то просто операции в пакете.
Ок
Как-то нужно "маркировать" то, что этот пакет есть реализация GUI. Может предположить, что все типы порождаются от вполне конкретного
родительского типа?
Тогда можно сделать этот тип пустым "контейнером" (smart pointer), просто хранящим ссылку на реализацию.
- доступ к (видимым) вложенным компонентам
через функции типа или пакета.
Наверное не столько компонентам, сколько данным?
- колбеки через формальные параметры
настраиваемых пакетов.
Хитрая идея... А на сколько это реально?
Типы, описанные в пакете (соответствующие компонентам)
можно сделать неограниченными, лимитированными дабы
запретить создание и присваивание вне пакета My_UI
Мне больше нравится smart pointer на действительно limited private with unknown discriminant part (правда, все tagged - have unknown
discriminant part)
--
Vadim Godunko
On Fri, Aug 05, 2005 at 06:55:20PM +0400, Vadim Godunko wrote:
Maxim Reznik wrote:
Может быть типа такого:
- файл описания интерфейса - это пакет на Аде.
Необычно для моего личного представления, но вполне разумно.
Кроме того момента, что мы сможем парсить этот файл
при помощи ASIS-а, хорошо еще и то, что этот
файл мы будем прямо использовать в with
внутри нашей программы.
А GUI-транслятор будет нам генерить тело для
этого пакета по файлу описания реализации XML.
Как-то нужно "маркировать" то, что этот пакет есть реализация GUI.
А зачем ? :-)
Может
предположить, что все типы порождаются от вполне конкретного
родительского типа?
Если надо маркировать пакет самого верхнего уровня, то это
можно сделать, потребовав чтобы он был дочерним от какого-то
предопределенного пустого пакета, типа "package GUI".
Но ты пишешь про типы, я не совсем понял про какие.
Это те которые по сути указатели на компоненты?
Да, можно сделать им общий корень, по идее.
Тогда можно сделать этот тип пустым "контейнером" (smart pointer), просто хранящим ссылку на реализацию.
- доступ к (видимым) вложенным компонентам
через функции типа или пакета.
Наверное не столько компонентам, сколько данным?
Да, к свойствам компонент.
- колбеки через формальные параметры
настраиваемых пакетов.
Хитрая идея... А на сколько это реально?
А что тут не реального? Нормальный Адский прием.
Ну может еще понадобится передавать в колбеки
данные пользователя, тогда прийдется сделать
еще механизм с передачей объекта.
Типы, описанные в пакете (соответствующие компонентам)
можно сделать неограниченными, лимитированными дабы
запретить создание и присваивание вне пакета My_UI
Мне больше нравится smart pointer на действительно limited private with unknown discriminant part (правда, все tagged - have unknown
discriminant part)
Тут меня терзают смутные сомненья. Дал ты юзеру smart pointer,
потом по логике приложения этот элемент больше не нужен и
может быть удален, но получается удалить его нельзя т.к. у
юзера есть на него ссылка. А потом юзер пытается что-то сделать,
активировать этот ненужный/почти удаленый элемент, мы что ему на
это скажем? Ну тот же пример с меню открытых окон, окно закрыли,
пункт меню удалился, а у юзера на него (пункт меню) smart pointer, и он его захочет активировать, как быть?
--
Maxim Reznik
Maxim Reznik wrote:
>- колбеки через формальные параметры
настраиваемых пакетов.
>Хитрая идея... А на сколько это реально?
А что тут не реального? Нормальный Адский прием.
Ну может еще понадобится передавать в колбеки
данные пользователя, тогда прийдется сделать
еще механизм с передачей объекта.
Вот хотелось бы уйти от передачи данных приложения в процедуры обратного вызова.
Тут меня терзают смутные сомненья. Дал ты юзеру smart pointer,
потом по логике приложения этот элемент больше не нужен и
может быть удален, но получается удалить его нельзя т.к. у
юзера есть на него ссылка. А потом юзер пытается что-то сделать, активировать этот ненужный/почти удаленый элемент, мы что ему на это скажем? Ну тот же пример с меню открытых окон, окно закрыли, пункт меню удалился, а у юзера на него (пункт меню) smart pointer, и он его захочет активировать, как быть?
После удаления объект переходит в состояние Destroyed. Попытка вызова любой его подпрограммы приведёт к возбуждению исключения. :)
А поскольку код реализации генерируется, то шанс обойти это поведение минимален.
--
Vadim Godunko
On Sat, Aug 06, 2005 at 09:46:47PM +0400, Vadim Godunko wrote:
Вот хотелось бы уйти от передачи данных приложения в процедуры обратного вызова.
Хорошо, пока не будем.
Вот еще один вопрос, который меня интресует. С простыми
типами данных (строки, числа, перечисления) как бы
более мение понятно. Хотя тоже, наверное нужено дать
юзеру способ указать функцию преобразования
числа/перечисления в строку. Тоже через формальную
функцию настраиваемого пакета? Или может через
переименование? Типа
with User_Data;
package My_GUI is
function Float_Format (X : My_Float) return Wide_String
renames User_Data.My_Format;
А вот как быть с более сложными типами для таких
хитрых виджетов, как Tree_View и Grid?
--
Maxim Reznik
Maxim Reznik wrote:
Вот еще один вопрос, который меня интресует. С простыми
типами данных (строки, числа, перечисления) как бы более мение понятно. Хотя тоже, наверное нужено дать
юзеру способ указать функцию преобразования
числа/перечисления в строку. Тоже через формальную
функцию настраиваемого пакета? Или может через
переименование? Типа
with User_Data;
package My_GUI is
function Float_Format (X : My_Float) return Wide_String
renames User_Data.My_Format;
А я бы не делал такого, точнее - оставил-бы разработчику собственноручно выбирать способ предстваления/преобразования данных внутри реализации.
Например, может когда-то и будет разработан пакет поддержки I18N (или хотя бы I10N) для Ada, но пока его нет придётся или самому что-то писать или использовать стандартные функции. В той же Windows всё это есть часть операционной системы, а следовательно изобратать самостоятельно - глупо. В Linux поддержка почти есть, но устроенна она совершенно по другому. Для Web задача значительно усложняется, а именно, использовать стандартные функции никак не удасться, поскольку они, как правило, ориентированны на использовании только одной локали в рамках одного процесса, а ведь Web сервером могут пользоваться одновременно много пользователей из разных стран и с разными установками предпочтений.
А вот как быть с более сложными типами для таких
хитрых виджетов, как Tree_View и Grid?
Хотел оставить этот вопрос на засыпку... Но ты меня опередил.
Ответ - не знаю. Хотя, конечно ничего сложного нет, если представить данные в соответствующем виде. Если интерфейс принимает своеобразное дерево (скажим, ASIS.Element) или массив/список записей/элементов (скажем, ASIS.Defining_Name_List), то по идее никаких сложностей не будет.
А вот как быть с "поисковыми" формами? Когда открывается пустая форма, пользователь задаёт критерии, по которым производится поиск и в той же форме отображаются найденные данные?
-- Vadim Godunko
Technoserv A/S
Rostov-on-Don, Russia
On Mon, Aug 08, 2005 at 11:37:46AM +0400, Vadim Godunko wrote:
Maxim Reznik wrote:
function Float_Format (X : My_Float) return Wide_String
renames User_Data.My_Format;
А я бы не делал такого, точнее - оставил-бы разработчику собственноручно выбирать способ предстваления/преобразования данных внутри реализации.
Да, с числами - плохая идея. А может быть такой механизм
нужен для перевода литералов перечислимых типов в строки?
True/False - Да/нет, пользовательских перечислимых
типов. Или это сделать тоже через локализацию?
А вот как быть с более сложными типами для таких
хитрых виджетов, как Tree_View и Grid?
Хотел оставить этот вопрос на засыпку... Но ты меня опередил.
Ответ - не знаю. Хотя, конечно ничего сложного нет, если представить данные в соответствующем виде. Если интерфейс принимает своеобразное дерево (скажим, ASIS.Element) или массив/список записей/элементов (скажем, ASIS.Defining_Name_List), то по идее никаких сложностей не будет.
Т.е. описывать универсальный тип, который будет пониматься
всеми реализациями мы не хотим? А как тогда? Кормить грид
любыми массивами структур? Это хороший вариант для
заранее определенных типов данных, но тогда как быть с
заранее не известными структурами? Как сделать грид для
select * from aaa если структура aaa заранее не известна?
В Аде я бы для этого делал так:
type Data_Kinds is (String, Integer, Date, Float);
type Cell (Kind : Data_Kinds) is
case Kind is
when String => Text : Unbounded_String;
when Integer => Int : Integer;
...
type Cell_Array is array (Cell_Index range <>, Positive range <>) of Cell;
---- Наполнение грида:
procedure Add_Data_To_Grid (Data : Cell_Array);
Ой, мне уже страшно представить как подумаю писать такой умный
транслятор. :-o
Деревья, наверное, по сути теже гриды только со ссылкой
на родительскую запись. Наверное наполнение будет аналогично
гридам.
А вот как быть с "поисковыми" формами? Когда открывается пустая форма, пользователь задаёт критерии, по которым производится поиск и в той же форме отображаются найденные данные?
А что тут особенного? Колбек будет наполнять грид
найденными данными, аналогично тому как это будет
при создании заполненной формы.
--
Maxim Reznik
Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти