Коментарии



Posted by Рустем Мухаметшин on May 04, 1999 at 09:07:54:

In Reply to: О событиях posted by Рустем Мухаметшин on May 01, 1999 at 02:40:32:

       Ну что ж, очевидно то что все вкладывают в понятие события свой смысл. Поясню что я думаю об этом.
(Рустем) Отличительной чертой является тот факт что ядро системы предоставляя стандартизированный интерфейс и механизмы обработки обращается к прикладной части системы для обработки специфической части задачи тем самым давая возможность на базе стандартизированного ядра создавать системы с широким спектром черт. .... В таких системах возникает понятие события, т.е. того момента когда ядро обращается к прикладной системе
         Я думаю, что понятие события введено здесь весьма широким образом. Сравнение с Windows было только примером и не претендавало на аналогию по механизму технической реализации. Я мало сказал о том как они должны осуществляться технологически (т.е. как, когда, откуда вызываться, запускаться, обмениваться, ...). Но что интересно, на список предложенных событий (в числе которых и существующие) не было ни одного замечания. А ведь он был составлен так что прояснял опущенные теоретические моменты.
Т.е. я думаю не нужно молиться на Windows. Нам не нужна одновременная обработка двух событий. В каждый момент времени сервер обрабатывает один запрос. Очень хорошо. В процессе обработки он сталкивается с массой вопросов о том как сделать, которые он пытается решить самостоятельно и естественно самым простым образом - ничего не делая. Т.е., к примеру,  вводится счет: ВОПРОС:Корректен ли запрос оператора? - СЕРВЕР:Раз отправил значит корректен, проверю только существовнаие родительского счета, ... (физическую целостность по структруе).
        (Дмитрий) в ФБП очень мало точек влияния на процесс ввода данных, еще меньше на пересчет. Поэтому очень трудно организовать сквозной контроль правильности базы данных. Когда то я предлагал Аркадию ввести в дереве специальный раздел, который бы выполнялся всего один раз в момент регистрации операции. Идея была в том, чтобы при вводе оперции в прошлое, если она содержит ошибку, отбрасывать ее. Потом пришла мысль, что в этом разделе можно было бы делать расчет, результат которого помещался бы в операцию в дополнительные поля. Так можно сделать систему нумерации документов.
Вот это действительно близко к тому что я имею в виду. Собственно и я когда-то начал с этого предложения.
   
     Еще раз предлагаю список событий
    1. При выполнении формы (существует обработка)
    2. При пересчете операции (существует обработка)
    3. В процессе ввода операции
    4. При вводе операции (в момент обработки запроса O)
    5. При вводе счета
    6. Дать шаблон кода счета
    7. При удалении операции
    8. При удалении счета
    9. При первом пересчете операции
    10. При недостатке памяти (приближении к нему)
    11. При ошибке
        Обработчики событий 2, 4, 7, 9 (возможно и 11) можно (и уже расположены 2) в дереве операций, в его ф/к. Очевидно что не во всех из них будет известно расчетное состояние к моменту операции, а это далеко не всегда и нужно. Обработчики событий 5, 6, 8 можно поместить в форме справочника в специальных секциях. Конечно возникают вопросы с передачей аргументов. Вероятно нужно делать предопределенные переменные. Событие 10 действительно несколько выбивается из этого ряда и имеет черты асинхронной обработки - ну чтож можно выкинуть, тем более если вернеться динамическое рапределение, но можно хотя бы сделать функции для написания формы слежения - статистика это не для всех.
Хочу так же отметить что по характеру это не прерывания. Т.е. обработка происходит стандартным чередом: запрос за запросом, операция за операцией.
        Вообщем, понятие события у меня не имело свойства асинхронности, как например в Windows или прерываний ОС. Под событием (возвращаясь к началу) понимается момент обработки когда возможно несколько корректных способов (направлений) решения обрабатываемой задачи, а значит серверу для сохранения гибкости и общности желательно обратится к прикладному коду.

        Вот как я вижу обработку с технической точки зрения.
Событие 4
        1) Сервер получает запрос O на ввод операции. Производит идентификацию по дереву.
2) Инициализирует переменные ветвей вопросов и выборов справочников. Запускает определенный в дереве ф/к (не участвующий в процессе пересчета).
3) Обработчик проверяет первичный контроль аргументов (да хотябы что введено 15,70 или 15.7)
4) В случае если все внорме обработчик прописывает в EXTRD необходимые данные (к примеру для организации нумерации первички, или же просто однократно обрабатываемую информацию о документе)
5) Сервер получив код возврата (хотябы и в $)   принимает или отвергает операцию.
Событие 9
        1) Здесь просто можно ограничиться предопределенной переменной флажком, которая проинформирует все ф/к в ветви первично обсчитываемой операции о том что это происходит первый раз. Отпадет в некоторой степени необходимость создания всяких сигнатур и сохранения в EXTRD флажков для тех кто работает этими методами. Ну и просто отпадет необходимость в повторных реквизитных записях EXTRD. А это насколько я убедился по профилеру от 50% и выше на моих настройках
Для экономии не буду расписывать остальное

        Вот и все.


Пpишедшие ответы: