Внешние обработчики классов

Прелюдия:
К сожалению, пока все это "правильно" не реализуемо, т.к. требует доработок ядра и новую версию клиента.
Однако считаю, что подобное решение серьезно расширит потенциал системы.

Спич:
для класса вводиться новый тип property - External.
Параметром этого свойства является имя dll и процедура внутри этой dll.

В процедуру внутри dll передается контекст подключени к БД и UDN. UI должен работать в рамках основного окна клиента (хотя возможно это и не обязательно).

Сами dll храняться в БД и подгружаются на рабочую станцию по необходимости при первом обращении к процедуре из этой dll.

CREATE PROCEDURE MyClass_getp_extprop
  @p1 int, @p2 int, @p3 int
AS
BeginProperties
 
ViewProperty 'view', 'Просмотреть документ'
ExternalProperty 'sendMail', 'Послать документ по e-mail', 'nxMail.dll', 'SendDoc'
ExternalProperty 'makePDF', 'Конвертировать в PDF', 'nxPrint.dll', 'MakePDF'
GO

Примерами таких свойств в текущей реализации являются печать и открытие файлов. Но сейчас они жестко прописаны в exe.
я считаю, что они должны быть реализованы в виде подгружаемых библиотек. В этом случае возможны разные версии печати, например, через VB форму и HTML форму.

Forums: 

Изображение пользователя ipanshin.

Примерами таких св

Примерами таких свойств в текущей реализации являются печать и открытие файлов.

Вот-вот, а это значит надо открыть файл (скажем pdf) в главном фрэйме клиента. Но Acrobat то не относится к приложениям семейства MS Office, так конечно он и не откроется. Нужен mfc класс pdf объектов. И ктож его будет писать?

А желание хорошее: открываешь в клиенте документ, работаешь с ним, потом прокидываешь вместе со всеми потрохами в pdf или любой другой тип. И все это в рамках одного главного фрейма. Здесь как минимум задача связки двух классов один из ктр типа MFC, а другой Nexus. Благородно, конечно, решить такую задачу.
За классом external стоит nexus class to mfc class. И ессно wrapping здесь не поможет. Пусть pdf открывает acrobat и в своем окне плиз. Это мое мнение.

Изображение пользователя st.

Я начало пропустил. А какова ц

Я начало пропустил. А какова цель этого расширения ? Може быть, можно обойтись без DLL, подгружать скрипты на JavaScript/VBScript ?

Кстати, я только недавно узнал

Кстати, я только недавно узнал что в MS SQL можно прочитать и записать файл в TEXT не прибегая ни к каким внешним средствам (EXE итд)

Изображение пользователя st.

В MSSQL, по-моему, еще в 6.5 м

В MSSQL, по-моему, еще в 6.5 можно было в ХП использовать COM-объекты. Но это все сторона сервера.

Вот-вот, а это зн

Вот-вот, а это значит надо открыть файл (скажем pdf) в главном фрэйме клиента. Но Acrobat то не относится к приложениям семейства MS Office, так конечно он и не откроется. Нужен mfc класс pdf объектов. И ктож его будет писать?

1. Не надо сужать задачу до работы только с файлами разных типов. Внешние свойства могут быть у любого класса NEXUS.

2. При чем тут MS Office? Речь идет о том, что свойство может быть выполнено на клиенте. Для этого процедура, которая его реализует, должна иметь специфицированный интерфейс (аналогично обработчикам на transact-sql), который, ессено, програмируется, а дальше этот обработчик может использовать любые библиотеки.

За классом external стоит nexus class to mfc class. И ессно wrapping здесь не поможет. Пусть pdf открывает acrobat и в своем окне плиз. Это мое мнение.

Еще раз повторяю, речь не о внешних классах, а о внешних ОБРАБОТЧИКАХ для классов NEXUS. Это, IMHO, существенное отличие в поставновке.
Ни какого преобразования класса не требуется, либо внешний обработчик работает с классом, который по структуре совпадает с классом NEXUS, либо то, с чем работает внешний обработчик - это один из атрибутов класса, который имеет сложную структуру и, как правило, будет храниться в BLOB.

Я начало пропустил. А какова цель этого расширения ? Може быть, можно обойтись без DLL, подгружать скрипты на JavaScript/VBScript ?

Термин DLL я применил в широком смысле - любая программа которая может динамически подключаться к приложению.
Цель следующая - создать клиента, который будет иметь четкую структуру и возможность расширения, без перелопачивая уже написанного кода.
Вот приблизительный начальный состав модулей:
nxFrame - основное приложение, которые выполняет функции установки и поддержки коннекта к БД, а так же управление подгрузкой и линковкой других модулей.
nxBrowser - стандартный проводник NEXUS. Если при регистрации, frame не получает информацию о том, какой browser использовать, то загружает nxBrowser.
nxPrint - стандартный модуль печати, который реализует свойства печати документов, так как они сейчас сделаны.
nxFile - стандартный модуль, для работы с классами, производными от File.

Изображение пользователя ipanshin.

1. Не надо сужать

1. Не надо сужать задачу до работы только с файлами разных типов

Я и не сужаю. Ведь nexus класс документов показывается в клиенте тоже при помощи MFC класса, а следовательно содержимое blobа или файла надо както показывать. А это реализация MFC. никуда не денешься и никуда не завернешь:)

При чем тут MS Office?

На это не заморачивайся. Просто я обнаружил способность MS приложений работать с файлами офиса, хоть я и не просил об этом, в отличие от других типов файлов.

Вопрос.
1. Все работает в одном главном фрейме или нет?
2. Внешний обработчик по отношению к клиенту работает с БД? и если работает то через nexus клиента? nexus клиент выступает как брокер коннекций?

либо внешний обработчик работает с классом

Если по выбору пункта меню будет запускаться процедура на клиенте или процедура в dll файле - это будет то?

Вот приблизительный начальный состав модулей

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

Изображение пользователя ipanshin.

MS SQL можно прочи

MS SQL можно прочитать и записать файл в TEXT

makewebtask или чтото другое?
Я с небольшим текстом работаю через nexus cntrlC - cntrlV. Очень похоже на карман засунул в карман - вынул из кармана:)

Вопрос.1. Все ра

Вопрос.
1. Все работает в одном главном фрейме или нет?
2. Внешний обработчик по отношению к клиенту работает с БД? и если работает то через nexus клиента? nexus клиент выступает как брокер коннекций?

1. Я не очень хорошо разбираюсь в окнах последних версий Windows, поэтому отвечаю, как ламер. Само окно которое откроет внешний обработчик может выходить за рамки окна фрейма, но если я завершаю работу фрейма, то все внешние обраблтчики тоже должны завершиться.

2. Да, коннект к БД устанавливает фрейм, обработчик получает уже установленный коннект для работы. Как вариант, обработчик вообще не работает с БД, а только запрашивает и получает данные от фрейма.
Не желательно, что бы обраблтчик сам устанавливал коннект к БД, т.к. ему надо передовать имя пользовтеля и пароль.
Прошу DT высказаться по этому вопросу, как системного архитектора.

Если по выбору пункта меню будет запускаться процедура на клиенте или процедура в dll файле - это будет то?

Да.

Изображение пользователя ipanshin.

Да.</blockquote>

Да.

Я думаю, что это уже сделано. Правда с выпадающим меню, которое относится к гриду в документе. Но можно это перенести и в основное выпадающее меню браузера nexus.

механизм будет таким

1. выбираешь свойство документа как обычно.
2. по этому свойству запускается процедура на клиенте, которая лезет в уже известную таблицу synch и вытаскивает путь и имя dll файла (ну м.б. и сам dll файл в виде blob, я еще точно не знаю)
3. если она находит этот файл, то идет динамическая подгрузка dll файла и вызов из него процедуры, которая связана с этим свойством
4.исполняется вызванная процедура (правда я пока не могу сказать как быть с передачей параметров ведь тогда априори спецификация параметров процедуры долна быть известна) Или построение dll должно подчиняться некоторой спецификации передачи.
5. после этого выгружается dll и далее по тексту

другое дело, если dll будет интерактивна и захочет открыть например pdf файл (уже избитый пример) без учета, что MFC класса pdf объекта нет. Т.е. dll должна быть самодостаточна и не надеяться на nexus.

опять же раз она должна работать с БД то эта связь не должна опираться на nexus. В противном случае dll без nexus не отладить. А заранее привязывать dll to nexus, то зачем этот геморрой нужен? Что легче дорабатывать клиента или разрабатывать dll к нему? Другое дело, что самого клиента разрабатывать по принципу: загрузил-выполнил-выгрузил dll. Ну так это старый оверлей. У нас что мало памяти?

Чехарда, сэр

все внешние обраблтчики тоже должны завершиться

внешние обраблтчики - это что уже отсоединенные процессы? В принципе можно синхронизировать по такой схеме: запустил процесс - процесс сразу кладет в synch свою строку - доработал процесс и убрал строку. В общем тут куча вариантов синхронной и асинхронной работу присоед. и отсоединенных процессов. В общем случае реализация проблематична.

Да, пообщался с 1С и ейными метаданными. Скажу сразу, что у nexus плюсы есть. Надо будет еще сблизиться, тогда чтонибудь и напишу.

MS SQL

MS SQL можно прочитать и записать файл в TEXT

makewebtask или чтото другое?
Я с небольшим текстом работаю через nexus cntrlC - cntrlV. Очень похоже на карман засунул в карман - вынул из кармана:)

Нет

http://msdn.microsoft.com/library/defaul...

см процедуру saveNtext2file

Изображение пользователя ipanshin.

Да, спасибо. Похоже на правду.

Да, спасибо. Похоже на правду. А вообще есть описание всего того, что лежит в master и ссылается на внешнюю dll? Тоже кстати подгружаемые:)

Изображение пользователя ipanshin.

СБ видимо хочет именно то, что

СБ видимо хочет именно то, что есть в этих процедурах. Организация потока (stream) между DB <-> nexus client <-> dll сквозняком.

Изображение пользователя ipanshin.

СБ тут не так все просто. Надо

СБ тут не так все просто. Надо определить прототип функции. какие будут предложения?

Скажем void func( UDN ); ?

Для макета, такой прототип год

Для макета, такой прототип годится.

А вот еще вопрос интересный: Кто управляет транзакцией?
Сейчас транзакцию начинает nexus.exe - любой обработчик выполняется в рамках транзакции.
Желательно сохранить такой порядок и для внешних обработчиков.

Изображение пользователя ipanshin.

Сейчас транзакцию

Сейчас транзакцию начинает nexus.exe - любой обработчик выполняется в рамках транзакции.

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

И потом. Для общения с БД, что не хватает нексус клиента? Что за ситуация такая, когда надо выполнять нечто из сторонней dll, которая общается с БД? Сторонняя dll нужна для работы с не нексусовскими классами, imho, а не для работы с БД. Я для этого и подгружаю сторонние классы к клиенту. А далее внутри нового класса действуют законы того, кто его писал, а вовсе не законы нексус-БД.

Рассуждения верные.Но в эт

Рассуждения верные.

Но в этом случае такой простой (и удобный интерейс) как void func( UDN ) уже не прокатит.
Нужна некоторая структура для обмена данными между nxBrowser и "внешней" dll. При чем ссделать ее универсальной проблематично, IMHO.

Ламерский вопрос: а dll может вызывать функции из приложения, к которому ее прилинковали?

Еще один акцент: когда я говорю "внешняя" DLL, я не имею ввиду использование компонент третьих производителей "как есть", для них требуется обертка, что бы такая компонент стала обработчиком внешнего свойства.

Изображение пользователя ipanshin.

Код: void func(

Код:
void func( UDN )
уже не прокатит.

поэтому и вынес на обсуждение. Вопросы интерфейса. В нексусе три целых числа. А здесь?

dll может вызывать функции из приложения, к которому ее прилинковали?

Она должна о них знать. Простой путь через H files на этапе компиляции. В остальном пока плаваю и не могу сказать уверенно.

как есть", для них требуется обертка,

Сережа, разворачивать некому:). Обертка эффектна при передача. А при диалоге получается следующее. Написал - завернул - развернул прочитал, вместо написал - прочитал. Конечно, если dll состоит из завернутой нексус процедуры, тогда без проблем. Подсоединил - развернул - прочитал то бишь выполнил.