Возникла необходимость сделать желательно довольно гибкую надстройку над 1С УТ 11 (платформа 8.2) которая бы имела нечто общее с системой плагинов в прочих программах.
Суть такова: одна централизованная обработка обрабатывает неким алгоритмом справочник номенклатуры. Алгоритм совершает почти одни и те же действия в целом, но требует для разных классов (назовём пока так - классов, чтобы не путать с терминами из самой конфиги) номенклатуры свой уникальный субалгоритм для данного класса номенклатуры. Причём желательно иметь возможность довольно легко дополнять эту систему новыми классами номенклатуры со своими субалгоритмами. Класс номенклатуры в рамках нашей конкретной задачи имеет вполне вещественный смысл и выделен в отдельный справочник. Хотелось бы максимально эффективно организовать встраивание в систему и собственно вызов вот этого субалгоритма, типа как плагина - иметь в справочнике классов номенклатуры возможность указать что за алгоритм мы будет использовать.
В голову сразу приходят несколько вариантов, но я считаю у них есть глобальные недостатки:
1. в классах номенклатуры завести текстовое поле неограниченной длины, куда прямо писать код субалгоритма, и вызывать его через eval.
жирным минусом я вижу трудность отладки. очень жирный минус.
2. в классах номенклатуры завести поле хранилище и грузить в него в нешнюю обработку, экспортные методы которой в дальнейшем дергать.
минусом я вижу долгое время приведения этого механизма в боеспособное состояние, а методы плагина должны дергаться довольно часто. т.е. буквально идем стандартным перебором по товарам и в зависимости от того какому классу он принадлежит дергаем метод плагина. надо как можно быстрее. кроме того, пока писал уже, дошло, что отладка опять в пролете.
Хотелось бы что-то совсем быстрое и достаточно удобное.
Зрел вариант заводить на каждый класс обработку в модуле менеджера которой экспортировать нужные функции. В справочнике же классов просто указывать имя обработки, а потом динамически в коде её получать и вызывать метод. Не получается так...
В общем есть ли еще какие варианты или какие мысли как улучшить то что я обдумывал?

(0) Если за ранее создать и закешировать обработки плагины то создание всех обработок перед стартом обработки займет секунд 5.

В некоторых случаях даже DLL у взрослых дольше подключаются.

Тебе надо определить сколько классов будет 10,100,1000?

нафига ?

если алгоритмы простые, то можно и полем обойтись, посмотри в сторону инструментов разработки, может сможешь прикрутить...

обработки подрубать и обрабатывать не так уж сложно, а по времени все очень спорно, а отлаживать обработки попроще будет


пока что любой плагин проще всего реализуется на обработках

Опять таки даже если у тебя будет 100 классов это подразумевает что записей у тебя более 10 000 даже в этом случае создание 100 обработок в кэш не займет много времени, да и создание во время выполнения (без кеша) не должно быть проблемой, темболее обработки у тебя будут простыми  и пустыми (без кучи форм). Мне кажется ты преувеличиваешь проблему.

А вот хранить в конфигурации "плагины" плохая идея т.к. придется еще добавлять механизм обмена плагинами (выгрузка загрузка) следить а коллизиями обмена, при этом получение алгоритма через "." тоже не бесплатно.

*Без кеша я имею в ввиду кшеа при старте, само собой что для каждого класса обработка будет создана только один раз.

и поковыряй механизм доп. обработок в БСП, может там есть что надо...

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

Еще один вариант суперуниверсальной обработки которая в конечном итоге никому будет не нужна

О, получилось по имени обработки дернуть её метод из модуля менеджера.
Т.е. Обработки[ Имя ].Метод(...) вполне работает, я запорол на том что пытался из клиента вызывать, а это в 8.2 прерогатива сервера.
Думаю это всяко быстрее чем динамически грузить обработку из хранилища. Кеш конечно можно сделать, но это сложностями обрастает. Отладка опять же в пролете.
А так получается всё что нужно на месте и самое главное - восьмерка позволяет обновлять конфигурацию базы динамически. Это для меня вообще лафа, т.к. как раз по ходу работы юзверей я смогу и обновлять базу без угрозы поломать что-то (меняется только алгоритм) и отладку делать и довольно быстро вызывать плагинообразный код.
Всё, вопрос закрыт. Всем спасибо!

> Еще один вариант суперуниверсальной обработки которая в конечном итоге никому будет не нужна

Нет, у неё конкретный практический смысл, который уже много лет работает под семеркой. Но там реализация абы какая, что-то во внешних обработках распихано, что-то через ЕСЛИ Товар.Поставщик.Код = ... Тогда ... короче труба.
Сейчас планируем переходить на восьмёрку заодно рефактрингом займусь.

1) нефик программировать в боевой базе
2) демоническое обновление зло

(9) я тоже радовался динамическому обновлению пока на одном из предыдущих релизов 8.2 не загнулась база. Сейчас уже эту проблему подправили, но осадок остался, так что теперь не пользуюсь.
(11) +100500

(9) и еще учти, что при динамическом обновлении что бы у пользователя алгоритмы поменялись он должен будет выйти и зайти
т.е. еще может оказаться, что у разных пользователей буде разный алгоритм, а это ИМХО хуже чем если он просто не правильный...
слушай что говорит (12)
у меня тоже осадок остался. не пользуюсь на боевых больших базах.

Смысл субалгоритма в том чтобы из внешних источников данных всякими разными способами извлекать информацию о товаре (цены, характеристики и так далее, сильно зависит и состав данных и его источник от того что я назвал классов товара) и скармливать общему алгоритму применению изменений. Поэтому нестрашно почти всё из вышеописанного, кроме естественно обрушивания базы. =) Хорошо, учту, творить "беспредел" с обновлениями буду только в тестовой.

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

Динамическое юзаю но все равно приходится перезагружать сервер 1с иначе потом конфигурацию не сохранить во внешний файл.

мы создали эталонную административную базу которая поставляет данные во все остальные рабочие боевые базы.

В эталонной базе содержатся классификаторы(профессий, номенклатура, услуги и пр.). В ней же обработки по заливке в нее данных откуда угодно.

Все остальные рабочие базы коннектяться по сом-коннектору в этой эталонной и потребляют единообразные данные и методы для всех, а все эти субалгоритмы и подклассы - от лукавого, сломаете зубы - инфа 100%

> В ней же обработки по заливке в нее данных откуда угодно.
> а все эти субалгоритмы и подклассы - от лукавого

Вы знаете такие слова, как "обобщение алгоритмов"?
У вас же тоже есть обработки по заливке данных - есть.
Чего плохого в том чтобы унифицировать их? Чего плохого в том чтобы облегчить правку старых или добавление новых алгоритмов без изменения центрального кода, раз уж есть к тому предпосылки?
В какой нибудь Java вокруг ничего классов и наследования разводят как вот по этой ссылке до маразма: http://www.gamedev.ru/flame/forum/?id=155128 (реально маразматично)
Но раз уж в 1С нет нормальных классов и наследования, то почему я не могу "отплагинить" код в модуль менеджера? Нормально всё. Попрет.

(0) У нас реализация обмена с ккм как раз 2й вариант.
Мы сделали причем еще несколько режимов...
Отладочный, при котором обработка берется не из хранилища, а из указанного пути, соответственно ее легко трассировать, а главного ничего не нужно переоткрывать, изменил, сохранил, нажал кнопку, сказка а не отладка, ненужно всякие обработки переоткрывать, предприятия перезагружать...
В планах сделать еще обновления по инету ну и прочие вкусняшки...

Я не понял какой менеджер модуля, при чем здесь обновление?

Ты хочешь это обработки хранить в конфигурации? И причем здесь тогда плагины?

> Я не понял какой менеджер модуля, при чем здесь обновление?

Менеджер модуля - это в 8.2 (да и в 8.1 наверное, не помню, я сразу на 8.2 прыгаю с семерки) это экспортные процедуры менджера объектов, т.е. не создавая документ или обработку как объект можно вызвать метод, например так:
Обработки.МояОбоработка.МояПроцедура/Функция(...), причём именно я, как программист, программирую этот метод.
В сущности сильно похоже на просто неглобальный общий модуль, но меня привлекла возможность делать так:
Обработки[ СтрокаСИменемОбработки ].МояПроцедура/Функция(...), где видно что можно завести кучу таких обработок и вызывать метод из любой из них параметрически по текстовому имени обработки.
Если такое есть у общих модулей - то еще лучше, но лично у меня так не получилось, ибо они не являются объектным типом конфигурации и обращаться к ним через ОбщиеМодули[ Строка ].Метод не получается.
А у всех обработок/справочников/документов такое есть и реализуется через так называемый "модуль менеджера". Есть в этом аналогия к статическому методу класса в большинстве ЯВУ, но тут еще можно какбе через рефлексию с этим работать, как в Яве какой нибудь.

Суть того что эти обработки я буду вызывать по строковому имени динамически, поэтому и аналогия с плагинами, хотя хранится они будут, да, в конфигурации.

Кривым решением попахивает... Давай-ка все по порядку и с самого начала. Что? Зачем? Откуда? По чьей инициативе?...

Что такое модуль менеджера я в курсе, но его нет во внешних обработках, т.к. он может быть  только у объекта конфигурации. Таким образом ты резко генеришь себе геморрой экономя на спичках.

Я не понимаю какой смысл хранить ПЛАГИНЫ в конфигурации?

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

Во всех остальных случаях гораздо проще делать внешние обработки и подключать их по мере необходимости.

(9) "Кеш конечно можно сделать, но это сложностями обрастает. Отладка опять же в пролете."

Какими сложностями?

Функция ПолучитьПлагинПоКлассу(пКласс)
  Плагин = глСоответствиеПлагинов[пКласс];
  Если Плагин= Неопределено тогда
    Плагин = ВнешниеОбработки.Создать(пКласс.ПутьКОбработке);
    глСоответствиеПлагинов.Вставить(пКласс,Плагин)
  КонецЕсли
  Возврат (Плагин)
КонецФункции;

глСоответствиеПлагинов =  Глобальная переменная соответствие или структура.

Отладка стандартная, открыл обработку плагина в конфигураторе и отлаживай сколько угодно.

не взлетит

Вообще нужно смотреть сколько у тебя конфигураций, сколько людей плагины будут разрабатывать может (22) прав и не стоит огород городить а тупо общий модуль в конфигурации выделить и все.

Минус плагинов в том что если у тебя в одном плагине есть удачная функция и тебе такую во втором хочется юзать это все выглядит не красиво.
А в общем модуле у тебя много функций общих будет. В итоге нужно взвесить все за и против. Но если ЗА то делай через внешнюю обработку

> Кривым решением попахивает... Давай-ка все по порядку и с самого начала. Что? Зачем? Откуда? По чьей инициативе?...

Что: закачка разнообразных свойств и атрибутов номенклатуры отличающаяся алгоритмом (сильно) в зависимости принадлежности её некоему поставщику - закачка информации из предоставляемого им прайса или похожего источника информации, коими могут быть, к примеру, диски с презентациями в HTML или даже Flash.
Зачем: да чтобы импортировать всё это многообразие не ручками, а программой и программист не парился добавляя нового поставщика ковыряя в глобальных модулях, а менеджеры не парились если заводят новый подраздел номенклатуры информационно изолированный от других, но для которого формат входных данных совпадает с уже существующим.

> Вообще нужно смотреть сколько у тебя конфигураций, сколько людей плагины будут разрабатывать может (22) прав и не стоит огород городить а тупо общий модуль в конфигурации выделить и все.

"Тупо общий модуль" уже в 7-ке был, даже лучше - с имитацией кое каких действий через вызов внешних обработок, для юниформности, но это же, блдаж, уровень бейсика:
ЕСЛИ Поставщик1 ТОГДА
ИМопртПоставщика1(...)
ИНАЧЕ ЕСЛИ Поставщик2 ТОГДА
ИМпортПостащика2( ...)
...

Маразм...

(27) А как ты еще хотел. Если это просто вызов одной функции, то лучше чем ты написал не будет. Мне недостаточно было для обработки разных банк-клиентов вызова одной функции. Я на каждый вариант банк-клиента написал обработку. У обработок есть стандартизированный набор экспортируемых реквизитов и методов, а в исходном документе создаю для каждого банк-клиента нужную обработку и дергаю ее методы, зная, что у всех обработок они есть. Больше по-моему ничего не придумать. Или суперобработка с супер Если Иначе.

Может чуше посмотреть в сторону организации на обработках? Типа внешних печатных форм. Также выделяем отдельный справочник, в нем сохраняем обработки определенной структуры, в справочнике номенклатуры просто добавляем реквизит, ссылающийся на этот справочник и готово. Тут тебе и удобство отладки, и простота в создании.

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

знакомо.. знакомо.. прайсы всяких по дискам/видео.. 95% кода загрузки одинаково, остальные 5% - почти под каждый прайс программить...

(29) Согласен. Сделал бы именно так. Забивать конфигурацию обработками, а потом их удалять, если поставщик отвалился.

(29) и тормозня в работе..

(32) а почему просто не закрыть код поставив соответствующие ограничения? зачем морочится с обработками, темболее что у заказчика будет 100500 архивных копий базы из которых он любые обработки достанет ?

Возьми Универсальную обработку подбора объектов и в ней используй Произвольный алгоритм, настройки которого хранятся в настройках пользователя и можно сохранить во внешних файлах. Каждый алгоритм может работать как отдельно, так и группой.

(33) какие тормоза?

Оппаньки... Не взлетает. =)
Концепт не вписывается краями в подлые рамки клиент-серверной архитектуры 1С 8.2.
В 8.2 сильные ограничения на клиент-серверное взаимодействие с целью забарывания клиент-серверного трафика...
Так, например, на клиенте недоступные очень многие ключевые объекты конфигурации типа СправочникОбъект и желанная мной конструкция Обработки[ ПоИмени ]... Оные вещи должны кодироваться на стороне сервера. Причем с сервера вызов методов на клиенте вообще не доступен.

Чёрт побери, но я то хотел так:
1. открываем обработку с унифицированным алгоритмом загрузки инфы о товарах от поставщиков
2. в ней указываем класс товаров (в сущности аналогия поставщика) в котором в строке указано имя обработки со стандартизированными методами, например "ЗагрузитьДанные( класс, путь_к_файлу_данных_или_урл )"
3. в этом "загрузить данные", вызванном из обработки динамически по имени происходят вещи типа открытия XLS, или DBF или Web и парсятся данные в один унифицированный формат набора структур данных о товаре.
4. эти извлеченные данные уже передаются в единый алгоритм "ПрименитьДанныеОТоварах( класс, данные )"

Проблема в том, что в 8.2 эксель или dbf по логике должны создаваться на клиенте, но мне чтобы вызвать обработку по имени нужно переключится в режим сервера и обратный вызов клиента с сервера, как я понял невозможен!
В принципе как вариант - передать каким то образом файл с данными от клиента серверу. Закачать его в бинарныеданные что ли и скормить вызовом? Чтобы сервер у себя сохранил во временный файл и открыл?
О боже, что-то кривовато выходит... Есть мысли как это должно работать "наиболее гармонично"?
Хочется вписаться в архитектурные особенности 8.2...

>>Проблема в том, что в 8.2 эксель или dbf по логике должны создаваться на клиенте

а?

> а?

Что "а?"? =) Человек НА КЛИЕНТЕ выбирает файл для загрузки. Он у него лежит, допустим в "мои документы". Как серверу до него добраться, а?

(39) ХранилищеЗначения - не поможет?

(0) механизм внешних печатных форм - не то?

ну и обработки заполнения табличных частей

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

(41) 0-ой пост уже не актуален, актуален (37)

(44) то же самое, см. УТ 11

(37) Чего ты паришься, у тебя все равно будет как минимум один вызов сервера, так как во время загрузки ты что-то куда-то будешь писать в ИБ.
По урлу загружай файл-источник во временное хранилище, на сервере уже перехватывай его и парси. Для описания разных процедур загрузки сделай общий модуль, где опиши алгоритм обработки данных для разных классов, у самих классов достаточно указать имя функции в этом общем модуле.
Как-то так я бы сделал, если правильно понял задачу.

(46)
Да, всё, примерно так и сделал. Только не в общем модуле процедуры специфичные для каждого поставщика - а в модуле менеджера обработок, для каждого постащика завожу одну обработку. Файл на сервер действительно пришлось передавать, но делаю не через ХранилищеЗначнения, а через "ДвоичныеДанные", по моему проще и как раз то что нужно.

Однако сейчас возник вопрос немного не по теме, наверное лучше новую тему завести, но попробую сперва задать вопрос в этой.

========================
=== НОВЫЙ ВОПРОС ТУТ ===
========================

Дело вот в чём - выгружаю сейчас конфигурацию (это стандартная УТ 11 + мои доработки) и размер получается 150 мегабайт cf-файла! O_o Дело в том, что мне его надо передавать по инету и заливать в рабочую базу. Накладненько это часто делать! Не ну я могу мирится раз в два-три дня эту операцию можно проделывать, но если мелкие доработки - проще вручную зайти на удаленный сервер и править там что ли. O_o

Нашел режим выгрузки только определенных модулей - может сильно помочь, если менялся только код, но тем не менее размер конфигурационных данных всё равно удивляет.
Добавил 3 справочника, пяток обработок и два общих модуля - размер подрос до 160Мб. На десять мегабайт эти изменения что ли потянули?! O_o Архивирование уменьшает на процентов 5 всего, несущественно совсем.
Это нормально в 8.2?
В инете какие то утилиты находятся типа ужимающие чего то - кто пользуется?
Чего можете посоветовать?
Подумалось - может создать типа "обновление конфигурации" - т.е. типа отпочковать свою конфигу через встроенный механизм поддержки конфигураций - но как мне показалось это поломает пусть уже подрезанный краями включением режима обновления объектов конфигурации, но тем не менее еще возможно хоть что-то могущим обновить механизмом поддержки УТ 11. Или это нормальный выход? Опять таки - может направите по верному руслу...

сделай поставку и .cfu rktgfq

клепай