В продолжение тем
Коллекции в 1С++ ( http://www.1cpp.ru/forum/YaBB.pl?num=1215152763/0 )
и 1sqlite ( http://www.1cpp.ru/forum/YaBB.pl?num=1214205575/251#251 )

предлагаю в этой ветке обсуждать универсальные интерфейсы выгрузки / загрузки данных.

Сейчас в 1sqlite и icpp 3.0 реализованы похожие интерфейсы для загрузки произвольных данных на базе CValue.

artbear писал(а) 15. Июля 2008 :: 08:35:


По поводу...
Можно вопрос чайника?
Предположим есть com-сервер, у которого есть метод возвращающий ссылку на массив
return @array
Нет ли способа получить как либо этот массив (ИТ или ТЗ) в среде 1С?
В массиве только простые типы.
Или только в цикле поэлементно?

artbear писал(а) 15. Июля 2008 :: 09:15:


Так как раз думаю. Появилась идея написать DCOM-сервер на FoxPro - тогда запросы можно выполнять
на физическом сервере.
Непонятно только как возвращать данные - через возврат простых типов долго,  через создание временных
файлов ДБФ - лучше, но не настолько...


P.S>В принципе же наверно лучше универсальный способ, не привязанного к конкретному com-серверу ?
Или просто нужен для тестов?

artbear писал(а) 15. Июля 2008 :: 10:01:


Было бы супер.  
Мир com-ов достаточно обширен, даже 1СV8:)

Пример кода(из докуметации) .
На сервере FoxPro
Цитата:

DEFINE CLASS t1 AS custom OLEPUBLIC
DIMENSION Arrayelement[3]
FUNCTION GetMyArray() AS array
   this.Arrayelement[1] = 1
   this.Arrayelement[2] = 2
   this.Arrayelement[3] = 3
   RETURN @THIS.Arrayelement
ENDFUNC
ENDDEFINE 

Вызов в Fox

ComServer=CreateObject("myserver.t1")
myArray=ComServer.GetMyArray()
?myArray[1]
?myArray[2]  

В прикрепленном файле реализация этого простого сервера.
Чтобы заработал нужно зарегить
myserver.exe /regserver
Убрать регистрацию myserver.exe /Unregserver

В icpp реализован еще один прокси-объект для загрузки в табличную часть документа.
Теперь метод ИТЗ::Выгрузить практически выродился и стал очень маленьким и простым, все на интерфейсах.

kiruha писал(а) 15. Июля 2008 :: 11:39:

А где ты Фокс собираешь? 9 версию где можно скачать нахаляву?
Халяву можно в личку написать

kiruha писал(а) 15. Июля 2008 :: 11:39:

При запуске ехе ругается на невозможность найти рантайм-библиотеку Фокса

artbear писал(а) 15. Июля 2008 :: 11:55:

Нашел библиотеки.

Если интересно - Создание сервера пошагово в Fox (по Клепенину)

1.Меню \"Новый проект" например myserver
2.Добавить програмный файл (prg) - в нем
3. Определить класс (написать строку)
DEFINE CLASS t1 AS custom OLEPUBLIC или другой
ключ слово OLEPUBLIC -т.е.  доступный по com
4. Добавить методы, например FUNCTION GetMyArray() AS array
5. кнопка Buld... Выбрать Win .../ com server(exe) - OK
- т.е. скомпилировать
6.меню Project \ Project Info \ закладка Server \Instancing - Single Use \ OK
создавать отдельные инстанции (экземпляры) com-серверов

Все - Можно работать на сервере с com-сервером

Для клиентов
7.установить и зарегестрировать у клиентов com-сервер
8. У клиентов в консоль mmc добавить оснастку службы компонентов
9. Служба компонентов \Мой компьютер \ настройка DCOM \ myserver\свойства- задаем где запускать приложение
(на сервере)
10. Дать права клиентам запускать приложение на сервере.

artbear
Доступ к 1C++ "ун. интерфейсам загрузки/выгрузки" будет из других яз. нпример Delphi,VB или только С++?

kiruha
Если будешь делать сервер к FOXу, то сделай пожалуйста TCP/IP сервер

artbear писал(а) 18. Июля 2008 :: 13:12:

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

kms писал(а) 19. Июля 2008 :: 18:31:

Да, именно из-за этого кода.
А вообще я согласен, просто хотелось узнать еще доп. точки зрения.

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

Если ты реально хочешь форсировать решение, давай начнем думать.
Итак, для возврата ошибки у нас будет функция GetLastError.

Достаточно иметь одну такую функцию на объект (как это предлагает Саша).
Или статус ошибки - это принадлежность конкретного интерфейса?

Аргументируй, пожалуйста.

artbear писал(а) 23. Июля 2008 :: 06:16:

Не, я имею в виду функцию GetLastError().

Достаточно одной такой функции на все интерфейсы (как у Саши)?
Или есть необходимость получать отложенно разные ошибки при использовании нескольких интерфейсов в одном объекте?
У нас пока GetLastError в инт. выгрузки принадлежит интерфейсу и ни с кем не разделяется.

artbear писал(а) 23. Июля 2008 :: 07:32:

Воот.

Теперь давай определимся, зачем они нужны.
Ведь схема работы у нас сейчас какая:

1. вызвал метод
2. получил код ошибки
3. если надо - получил расшифровку ошибки.

Привязка расшифровки ошибки к конкретному интерфейсу (а не к объекту) позволяет менее строгую схему:

1. вызвал метод интерфейса А.
2. получил код ошибки
3. вызвал метод интерфейса Б
4. получил код ошибки
5 получил расшифровку ошибки Б
6. получил расшифровку ошибки А

Т.е. есть возможность использования "отложенного" получения расшифровки для интерфейса.

С другой стороны, при возникновении ошибки в первой схеме, мы запросто реализуем те же возможности, просто забирать ошибку (копировать к себе) надо сразу.
Так стоит ли овчинка (с разнесением расшифровок ошибок) выделки?

artbear писал(а) 24. Июля 2008 :: 11:57:

Наверное к концу недели я становлюсь излишне ортодоксален.
Но нет, не убедил.

Есть несколько вариантов исправления.
Нужно выбрать лучший

1. Просто перебираем в объекте-КОП всех наследников и ищем первого предка, что реализует универсальный интерфейс загрузки

2. Научить класс CComponentClass для самостоятельной реализации интерфейс загрузки.
Но в этом случае неясная ситуация с классом, у которого нет предков с реализованным интерфейсом загрузки. Единственный выход - это выдавать ошибку в методе интерфейса ldrInit

Зато в этом случае КОП может четко узнать о загрузке данных в его предка. Например, можно сделать 2 метода-события, вызываемых до загрузки и после загрузки.

3. Или пойти еще дальше и делегировать в сам объект КОП интерфейс загрузки, чтобы КОП мог также служить приемником выгрузки.

Например, если в КОП-е есть методы
Число РеализуемИнтерфейсЗагрузки() - или это лишний метод в этом случае?
Число СобытиеЗагрузки_НачалоЗагрузки(КолвоКолонок, КолвоСтрок)
Число СобытиеЗагрузки_ДобавитьКолонку(...)
Число СобытиеЗагрузки_ДобавитьДанные(Контейнер) - сюда передавать какой-нибудь контейнер, проще всего Вектор.
Число СобытиеЗагрузки_ОкончаниеЗагрузки(КолвоКолонок, КолвоСтрок)

Если же этих методов нет или РеализуемИнтерфейсЗагрузки возвращает 0, тогда используем п.2

Мне лично п.3 очень нравится

kms писал(а) 25. Июля 2008 :: 09:50:

Да, для загрузки само собой.
"если класс не реализует интерфейсы загрузки" будем определять как?
наличием в классе всех 4-х обработчиков "СобытиеЗагрузки_" ?

Для универсальности завел еще один интерфейс IQueryInterface_Loader_Unloader c методами
BOOL IsLoader() и BOOL IsUnloader()
типа если классу нужна вариативность с поддержкой интерфейсами загрузки/выгрузки (как у КОП), то он реализует данный интерфейс и обязан реализовать соответствующие интерфейсы загрузки или выгрузки.
Если вариативности не нужно, все остается как сейчас.

ЗЫ интерфейсы рулят

А как я для CComponentClass должен поступить - когда КОП может реализовывать интерфейс, а может, не реализовывать, т.е. проверка на этапе выполнения
А CComponentClass должен на этапе компиляции показать реализацию унив.интерфейса загрузки.

Я потому и спрашивал ранее, может быть, в ldrInit тупо возвращать код ошибки ?
ИМХО иначе без спец.интерфейса подтверждения реализации унив.интерфейса загрузки/выгрузки не обойтись

ЧТо скажешь?

kms писал(а) 25. Июля 2008 :: 11:12:

Как раз чтобы универсально опрашивать любой объект и нужен подобный интерфейс
Не хочется, как всегда, вставлять блоки типа if(type)

Почему будут проблемы при 1sqlite ?
1. у нас пока что интерфейсы все-таки разные
2. как интерфейсы совпадут, проблемы быть не должно при нормальной реализации интерфейса.
Пример - ПоставщикТП в виде класса 1С++

Ну, в принципе, если тебе надо помоделировать - то не вопрос.
Только не заставляй меня в векторах (например) поддерживать еще и интерфейс IsLoader_Unloader.
Лучше поколдуй над CComponentClass, а если что, подумаем, не надо ли чего улучшить.

kms писал(а) 25. Июля 2008 :: 11:21:

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

artbear писал(а) 22. Июля 2008 :: 08:45:

Ну, родил типа наконец интерфейсы и реализацию для векторов.
Получилось, на мой взгляд, нормально.

Если поглядеть на код Вектор::Загрузить() и Вектор::Выгрузить(), то становится довольно забавно.
Когда-нибудь две телефонные трубки соединять доводилось, чтобы дружбаны могли между собой побазарить?
Вот так, коллекции ничего не нужно, кроме реализации двух симметричных интерфейсов.
То же самое можно сделать для остальных контейнеров и прокси-объектов.

По интерфейсам: в принципе, можно использовать.
Я постарался дать развернутое описание, и здесь важно в реализации его поддержать аккуратно.
В том числе - корректно обработать критичные и некритичные ошибки и 0, возвращаемый Init в nRowCount.

Насчет nRowCount у меня остались сомнения, нужен ли он вообще.
Да, теоретически его можно где-то применить для оптимизации получения данных.
Но случай такой так и не представился, так что я серьезно задумываюсь, стоит ли здесь усложнять интерфейс.

Еще описание Загрузить в доку забыл занести.

kms писал(а) 29. Июля 2008 :: 08:06:

Так ты прочти выше мою фразу.
Я предлагаю юзать Done только при успешном завершении выгрузки!
Done уже пригодился для выгрузки в ТЗ на форме.
Еще может пригодиться для какого-нибудь контейнера, который может каким-то образом оптимизировать выгрузку, например, кешируя данные в ldrAddRow и отправляя их окончательно только в Done - т.е. скорость за счет памяти и т.д.

т.е. Done - нужная вещь

artbear писал(а) 29. Июля 2008 :: 08:39:

Знаешь, я подумал и согласился.
На самом деле, независимо от результата операции, Done нужно вызывать, чтобы закрыть какие-то сетевые подключения, освободить какие-либо блокировки и т.д.

Но теперь Done - обязателен в том числе и при неуспешном завершении.
Ибо и в случае неуспеха также необходимо освобождать ресурсы.
В принципе, это несложно сделать - для коллекций достаточно было добавить два смартпойнтера.

P.S.
Да, и Done - теперь типа деструктора, исключений не бросает и ошибок не возвращает.
Соответственно, инициатор коды ошибок Done проверять не обязан.

kms писал(а) 29. Июля 2008 :: 09:16:

"Но теперь Done - обязателен в том числе и при неуспешном завершении." - так сделаем?
Тогда нужно исправлять реализации универсальной выгрузки для ИТЗ - Выгрузить и ВыгрузитьСтроку + коллекции (Вектор/АссоцВектор).
Ты их исправлял?

Исправил остальное - ldrDone сделан обязательным.

Кстати, для проверки различных загрузчиков нужно сделать тесты для проверки копирования значений.
А то вдруг где-то мы ошиблись, и происходит передача по ссылке в новый контейнер