Статья | |
---|---|
h.i.a. Автор Сообщений: 4002 Откуда: Мурманск/Спб/Мск Дата регистрации: 18.11.2005 |
Идеи написать несколько статей по VFP посещают меня уже давно. 15 лет стучания по клавишам (кому-то из ветеранов эта цифра наверняка покажется смешной) дают свои результаты. Есть определенный объем накопленных знаний, иногда возникает желание им безвозмездно поделиться.
Вкратце опишу содержание первой статьи. Она будет посвящена реализации технологии "подписки на изменение состояния объектов". Первый уровень подписчиков (назовем его локальный) - объекты, находящиеся внутри окна. Второй уровень (глобальный) - сами окна. Функцию рассылки уведомления об изменении состояния выполняет "Служба оповещения". Сразу отвечу на вопрос: зачем все это надо? Рассматриваемая технология решает проблему жесткой связи объектов. Отправитель уведомления полностью изолирован от получателей. Он "не знает" их названия, количества и месторасположения. Хочется услышать мнение сообщества о ценности (или бесполезности) предлагаемого материала. Исправлено 1 раз(а). Последнее : h.i.a., 01.07.07 14:28 |
Re: Статья | |
---|---|
Владимир Максимов Сообщений: 14095 Откуда: Москва Дата регистрации: 02.09.2000 |
Больше статей, хороших и разных! (почти цитата
После определенного количества лет "стучания по клавишам", практически любая статья выливается не столько в тонкости описания той или иной реализации на конкретном языке, сколько общей идеологии (стратегии и тактики) решения описанной проблемы. А вот это-то и составляет то ценное, что останется даже в случае, если кто-то перейдет с FoxPro на другие языки программирования. Знание не команд, а идеологии решения тех или иных проблем. Хотя, конечно, и собственно способ реализации на FoxPro описать не помешает ;) Правда, я не понял, о чем собственно статья будет. Но думаю из самой статьи что-нибудь пойму. |
Re: Статья | |
---|---|
DIMM@ Сообщений: 522 Откуда: Витебск Дата регистрации: 21.03.2006 |
Конечно писать!
Кстати не об этом ли приблизительно идет речь? www.javaportal.ru |
Re: Статья | |
---|---|
h.i.a. Автор Сообщений: 4002 Откуда: Мурманск/Спб/Мск Дата регистрации: 18.11.2005 |
Спасибо за поддержку. Нет, немного не об этом. Служба оповещения в отличие от Посредника не содержит ссылок ни на отправителя, ни на получателя сообщения. Основная его задача - оповещение подписчиков об изменении данных. Например, при изменении наименования товара в справочнике новое наименование автоматически обновляется во всех открытых окнах, подписанных на прием уведомления об изменении справочника товаров. Какие окна будут открыты пользователем в момент изменения предугадать невозможно. Исправлено 1 раз(а). Последнее : h.i.a., 04.07.07 15:13 |
Re: Статья | |
---|---|
Dag Сообщений: 1156 Дата регистрации: 08.02.2006 |
Жду с огромным интересом. Хорошо бы сразу подкрепить теорию работающими классами.
|
Re: Статья | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Hi h.i.a.!
А какая реализация используется (в общих чертах)? Фоксовое позднее связывание? ------------------ WBR, Igor |
Re: Статья | |
---|---|
h.i.a. Автор Сообщений: 4002 Откуда: Мурманск/Спб/Мск Дата регистрации: 18.11.2005 |
Цикл по формам/объектам и проверка наличия у объекта подписки на конкретное "уведомление". Объект может быть подписан на любое количество уведомлений. |
Re: Статья | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Hi Михаил!
Ой не, это чрезвычайно неэффективное решение BindEvents() значительно лучше ------------------ WBR, Igor |
Re: Статья | |
---|---|
h.i.a. Автор Сообщений: 4002 Откуда: Мурманск/Спб/Мск Дата регистрации: 18.11.2005 |
Здравствуй Игорь.
Чем же оно "чрезвычайно неэффективно"? Перебрать в цикле 10 открытых окон или 20 контроллов? Поверь, проблем со скоростью при таком подходе нет. Связка bindevent предполагает обязательное наличие отправителя и получателя. Допустим, пользователь открыл 10 окон, открыл форму редактирования какого-нибудь справочника и изменил наименование. Форма редактирования не может "знать", сколько окон используют данный справочник. Возможно все 10 окон, а возможно и не одно. Также, как и "окна-подписчики" не знают, открыта или нет "форма-отправитель". К тому же, одно окно может отправлять оповещения нескольких типов, также как и "окна-подписчики" могут подписаться на несколько оповещений. Я считаю, что bindevent очень удобная и полезная функция, но в данном случае ее использование неуместно. |
Re: Статья | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Hi Михаил!
Ну если формы простые то может быть, а если они сложные? Если там пользовательские визуальные классы применяются? Тогда надо не 20 контролов обходить (при этом возможно довольно глубоко вложенных) а гораздо больше - при этом определять их тип... А подписка не обязательно должна быть "напрямую" - вполне можно через специальный класс-посредник сделать. В примитивнейшем случае даже просто в goApp завести "событие" которое и дёргать при любом изменении - т.е. тот кто хочет подписаться - всегда знает на что ему подписываться, а тот кто публикует - всегда знает что дёргать... BindEvents это просто способ настроить кучу "мягких" связей между объектами. Он не диктует кто должен событие публиковать. Просто в других языках может и не оказаться возможности "обойти все открытые формы" ------------------ WBR, Igor |
Re: Статья | |
---|---|
h.i.a. Автор Сообщений: 4002 Откуда: Мурманск/Спб/Мск Дата регистрации: 18.11.2005 |
Здравствуй Игорь.
Насколько сложные? В реал-тайм системах с сотнями событий в секунду перебор мог бы стать "узким" местом... Какое количество объектов должно быть на форме, чтобы их обход вызвал заметную задержку? Миллион ? Боюсь, узнать не удастся, фокспро не переживет инициализации такой формы Обработка вложенности объектов (контейнеры и страничные блоки) в решении реализована, а классы по-умолчанию должны быть "пользовательскими" (решение не исключает использование базовых контроллов, но уведомления они получать не смогут). Тип объекта значения не имеет. Служба оповещения является промежуточным классом, но реализация отличается от паттерна "Посредник", упомянутого DIMM@ Если стандартной возможности обхода не предусмотрено, можно создать коллекцию форм, в init/destroy соответственно добавлять/удалять элементы. Если и этой возможности в "другом" языке не окажется, стоит задуматься нужен ли такой язык |
Re: Статья | |
---|---|
Prudivus Сообщений: 4283 Откуда: Кишинев Дата регистрации: 14.12.2006 |
У меня подобный функционал реализован через пару методов в базовом классе форм: getMessage(msg_type, msg_body) и sendMessage(msg_type, msg_body, form_name, form_class). По мере надобности форма рассылает сообщения (об изменении каких-то своих свойств, данных и т.п.), одной форме, группе форм (классу) или всем открытым формам сразу. Принимающая форма анализирует сообщение и реагирует на него. Типичные сценарии:
- изменение данных таблицы Т1 -> обновить курсор, связанный с Т1; - выбор из справочника (без его закрытия, множественный последовательный) -> добавить строку; - перемещение формы на экране (для "привязанных" и/или дочерних форм) -> переместиться вместе с главной формой. Делать ли для подобных задач (именно в фоксе) посредника - вопрос весьма спорный. |
Re: Статья | |
---|---|
Dag Сообщений: 1156 Дата регистрации: 08.02.2006 |
На это можно посмотреть?
|
Re: Статья | |
---|---|
Prudivus Сообщений: 4283 Откуда: Кишинев Дата регистрации: 14.12.2006 |
К кому вопрос? |
Re: Статья | |
---|---|
h.i.a. Автор Сообщений: 4002 Откуда: Мурманск/Спб/Мск Дата регистрации: 18.11.2005 |
Он у Вас уже сделан, так как разорвана связь между отправителем и получателем посредством интерфейса sendMessage/getMessage. В отличие от моей реализации у Вас все "прикручено" к классу окна. Я стараюсь придерживаться подхода Мартина Фаулера: лучше определить несколько "маленьких" классов, хорошо выполняющих свои "маленькие" задачи, чем один универсальный. Спорить из-за этого нюанса не вижу смысла, оба подхода имеют право на существование, суть от этого не меняется ------------------ |
Re: Статья | |
---|---|
Dag Сообщений: 1156 Дата регистрации: 08.02.2006 |
К Вам. |
Re: Статья | |
---|---|
Prudivus Сообщений: 4283 Откуда: Кишинев Дата регистрации: 14.12.2006 |
Фактически да, хотя можно было бы сделать еще класс диспетчера сообщений, как предлагал Игорь Королев. Цитата:Код довольно простой. В базовом классе моих форм определены два метода:
Пример посылки сообщения об изменении в данных:
Формы, в которых необходимо расширить базовый функционал, могут переопределять/дополнять метод getMessage, например:
Например, нужно обработать события перемещения главной формы формсета. Метод moved главной формы:
|
Re: Статья | |
---|---|
Dag Сообщений: 1156 Дата регистрации: 08.02.2006 |
Prudivus
Спасибо. Интересное решение. |
Re: Статья | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Hi Вадим!
Мне никогда не нравились идеи с обходом коллекций, и тем паче идеи спам-технологий Зачем нужно рассылать измещения всем-всем-всем, даже если им это неинтересно. И опять таки как по простому разрешить проблему пользовательского контрола - он то не сможет получить извещения...
Ну и далее всё просто. Тот кто хочет "оповестить" делает
В качестве "событий" можно использовать не только методы goApp, а например свойства динамически добавленные к _SCREEN (если не нужны параметры)... Все знают про goApp, но никто не знает о подписчиках и генераторах событий (они никак не связаны - хотя если надо, то одним из параметров генератор может передать ссылку на самого себя). Вот эту схему я понимаю А обходы _SCREEN.Forms а в общем случае ещё и рекурсивный обход вложенных в форму контейнеров - это есть некрасиво. Ессно что для VFP7 и ранее это не годится. AFAIK подобная схема может применяться в C#. И не нужно никаких "форм" или их коллекций для работы. ------------------ WBR, Igor |
Re: Статья | |
---|---|
Prudivus Сообщений: 4283 Откуда: Кишинев Дата регистрации: 14.12.2006 |
Согласен, эта схема красивее. Мой вариант писался еще для VFP6. Хотя, конечно, и для VFP6 можно было бы реализовать подобную схему, но "чуть большей кровью".
Изначально ставилась задача отобразить изменение данных в другой, заранее неизвестной открытой форме. Эта проблема появилась после перевода БД на MSSQL и, соответственно, использования Remote View. С родными фоксовыми таблицами все рефрешилось автоматом и проблемы не было. Потом оказалось что система сообщений может применяться и для других целей... Привязывать контролы разных форм друг к другу - пока с такими потребностями не сталкивался. Исправлено 1 раз(а). Последнее : Prudivus, 25.07.07 19:39 |
© 2000-2024 Fox Club  |