[sukhanchik]

Цитата:

Сообщение от grishin

Имеем один универсальный алгоритм на любое количество отчетов.
Это дало возможность не программерам каждый раз следить за отчетами,
а самим пользователям корректировать шаблоны как им надо.
Они просто ставят оговоренные метки в нужное место шаблона.
Есть определенный алгоритм разделения меток шапки и табличной части.

Любая универсальность усложняет поддержку. Я тоже такую машинку писал - для Word/Excel. Также с разделением шапки и табличной части. Правда не заморачивался выковыриванием именованных ячеек, а просто полагался на корректность настроек машинки, ибо сложность решения ошибки с лихвой компенсировалась ее некритичностью.

Из плюсов такого подхода:

• Кажущаяся универсальность на этапе проектирования (=можно выбить бюджет)
• Возможность заполнения шаблона по принципу 80/20, т.е. легкое автоматическое заполнение 80% полей в шаблоне
• Возможность корректировки шаблона Word/Excel пользователем

Из минусов:

• Универсальности нет. Вот нет и все. Обработкой каждого отчета все равно занимается свой класс, несмотря на настройки. Настройки могут помочь в выводе информации, но не помогут в ее формировании. Конечно классы являются наследниками, иерархия, почти как наследники RunBase, но ... все же каждый класс индивидуален. Особенно это заметно, когда используется табличная часть, т.к. там используется цикл, уникальный для каждого отчета.
• Сложность настройки. В качестве источника данных для именованных диапазонов могут быть поля таблиц и дисплей-методы (у меня было так). Даже если не брать в расчет дисплей-методы - то какими же знаниями должны обладать пользователи, чтобы уметь выбрать правильное поле при создании настройки? Особенно учитывая тот факт, что даже в стандартном функционале поля именуются так - что пока не узнаешь, как они называются в АОТе - не поймешь, какое поле требуется выбирать. При этом пользователь обычно не видит, какое поле в терминах АОТа используется в обычной форме, хотя может и знать - что ему надо именно это поле. Про дисплей-методы вообще можно забыть - тут ориентация нулевая. Кстати - при настройке - каким образом облегчается жизнь настройщика? Или он должен знать все поля и методы на таблицах?
• Неуниверсальность настройки. Представьте себе - вам нужно вывести в одном случае фразу из БД (например, название региона) в именительном падеже, а в другом - в родительном. Это будет 2 источника данных? А настройщик не запутается? А если нужно вывести 3 суммы - без НДС, с НДС и НДС - тоже в именительном и родительном падеже? Без программирования (даже минимального) не обойтись. А если программировать - то зачем тогда себе усложнять жизнь настройками?
• Переносимость настройки. Программный код переносится легко через XPO. Легко - означает в один клик по проекту. А при импорте - можно сравнить - что поменялось. Плюс есть система контроля версий кода. Обладает ли этим утилита переноса данных? (Группа определений или еще какая?). А можно ли "оптом" переносить настройки ? Например, также легко, как модели в АХ 2012 или приложение в АХ 2009.
• Отладка настроек. В состоянии ли настройщик адекватно проанализировать - что у него не получается в настройке? Или должен постоянно звать программиста? Если должен звать - то см. пункт выше - зачем тогда себе усложнять жизнь настройками?
• При подготовке шаблона нужно уделять тщательное внимание именованию ячеек/закладок и следить за тем, чтобы их названия были понятны настройщику. Иначе все опять скатится до программиста.

Так что тут палка как говорится о двух концах...