|
Участник
|
Тихо сам с собою, я веду беседу...
Пока все молчат, я продолжаю биться о стену. Письменное изложение мысли помогает самому разобраться в проблеме.
Частично удалось задружить NAV с Text. Для начала выяснилось, что преднастроенные страницы интеграции нифига не работают, нужно использовать свои, со своей страницей удалось выгрузить из НАВа в Текст.
Почему частично? Потому что НАВ отдаёт записи по одной, в то время как Текст ожидает пачку записей. Это приводит к тому, что каждая отданная НАВом запись просто перезаписывает предыдущую. В итоге мы имеет в файле не пачку изменений, а только последнее изменение.
С одной стороны даже логично, ведь тип страницы у нас Card, давай попробуем сделать List. Хм, если тип страницы List, то НАВ вообще не отдаёт изменений, это уже далековато от логики...
Это всё наталкивает на мысль, что и XML с НАВом подружить не получается потому, что XML хочет отдать пачку записей, в том время как НАВ ждёт только одну. А что бы пачку отправить, надо по идее ещё и контейнеры смапить, а не только поля. В пользу этой теории говорит то, что при попытке смапить контейнеры, ошибки на полях исчезают, но появляется ошибка на мапинге контейнера. Дескать, а вот нельзя мапить Contact с Dictionary 2.
Почему 2, не понятно, но если расковырять адаптер НАВа, то можно увидеть как решили проблему того, что код адаптера статичен, а вебсервисы динамические на всю голову. А решили это тем, что для записей не создаются классы-контейнеры, вместо этого используются словари (тот самый Dictionary) у которых ключ - текстовое название поля, а значение, есть значение поля.
Подводя итог:
То что НАВ выплёвывает записи по одной, очень грустно и печально, надеюсь что я просто не знаю как заставить его выплёвывать пачку записей. Кстати, судя по внутренностям dll НАВ адаптера, он таки должен уметь плеваться пачками. Если конечно в клиенте Адаптера чего-нить такого не захардкодили, что ведёт к тому, что из НАВа записи обрабатываются только по одной. Хотя, тут наверное тоже может иметь место быть проблема с различными типами контейнеров...
То что в НАВ нужно отправлять словари, а не экземпляры классов (это ещё проверить надо, как бы по одной записи не пришлось фигачить), тоже грустно, тут судя по всему нужно либо передавать данные построчно, тогда и контейнеры мапить скорее всего не нужно будет, но это как-то убого с точки зрения архитектуры. Либо отдающий адаптер кодить так, что бы он словарь отдавал, а не экземпляр класса. Либо же, ИМХО, наилучшим вариантом будет заюзать функционал расширения мэппинга, написав функции, которые будут конвертить словари в объекты и объекты в словари. Тоже конечно не идеальный подход (вся динамичность идёт лесом), но других вариантов я пока не вижу.
|