Значение display метода по его названию

[Yprit]

Цитата:

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

Простите, а чем это отличается функционально от выбора в какой-либо настройке некоего значения Enum'а

1. Отсутствием контроля типов, правильности сигнатуры и т.п. в момент компиляции - все ошибки полезут в рантайме
2. Невозможностью использования перекрестных ссылок

В принципе, еще куча мелких проблем. Для знакомства со всеми ними достаточно плотно поработать с модулем "Расчеты с персоналом", функционалом счетчиков, например. Дебажить... Да, только и остается, что дебажить - втрое больше времени занимает, но ничего другого нам не оставили.

[TasmanianDevil]

Цитата:

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

1. Отсутствием контроля типов, правильности сигнатуры и т.п. в момент компиляции - все ошибки полезут в рантайме
2. Невозможностью использования перекрестных ссылок

В вопросе ключевым словом было "функционально" и по сути своей больше к консультанту относилось. Именно функционально в плане работы логики - фактически ничем не отличается. Про программиста в принципе изначально ясно было.

Про перекрестные спасибо - совсем про них забыл что-то я.

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

[mazzy]

Цитата:

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

N-угольные колеса вместо круглых ?
А потом при появлении нового варианта перетачивать на (N+1)-угольное, то бишь допрограммируя ?

Можно я повторюсь?

Цитата:

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

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

[mazzy]

Цитата:

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

один из возможных путей построения всяких удобностей.

Удобностей для кого?
Можно привести примеры удобностей?

[axaLearner]

Имхо, нормальная задача. Как пример, универсальный генератор отчетов. Создается word - шаблон с закладками. В настройках системы этот шаблон указан. И есть функциоанальность настройки этого отчета - открывается форма вроде SysQueryForm, где в гриде показаны все закладки нашего шаблона, пользователь может скомпоновать запрос (стандартное добавление источников данных в SysQueryForm) и каждой зайкладке поставить в соответствие поле либо display метод, что особенно критично если принять во внимание невозможность создания больших и вервистых запросов в связке DAX + MSSQL. Предположим этот отчет вызывается из карточки сотрудника; пользователь запускает отчет, который из отфильтрованного по текущему сотруднику Query, тянет поля и методы источников данных в отчет.
В принципе, программировать все равно надо, но для добавления нового отчета надо всего лишь добавить в параметрах системы ссылку на его шаблон и сделать кнопку на форме. Но согласитесь, очень удобно то что пользователь может сам добавлять новые закладки в шаблон и без участия программиста связывать их с источниками данных системы, вносить изменения.
PS. Мы такое реализовали на одном из проектов, как раз в модуле управления персоналом.

[mazzy]

Ваше описание основано на одном предположении

Цитата:

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

пользователь может скомпоновать запрос

Вы всерьез уверены, что пользователь СМОЖЕТ скомпоновать запрос? Тем более в форме, подобной SysQueryForm?
По-моему, вы привели замечательный пример... хм... не "человекоориентированного" подхода

Да, я знаю, что такие пользователи есть. Но их единицы. Мы рассказываем о такой возможности SysQueryForm всем пользователям. Но пользуются этой фичей единицы. И то только если консультант создаст запрос и сохранит его в списке используемых запросов.

Итак, повторюсь: вы делаете, делаете некую супер-фичу. Ваша супер-фича основывается на том, что пользователь будет формировать запрос.
Вы всерьез уверены, что пользователь СМОЖЕТ скомпоновать запрос?

[axaLearner]

Цитата:

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

Ваше описание основано на одном предположении...

Если вы склонны цепляться к словам, то я лишь уточню, что под пользователем системы я имелл ввиду человека, который будет настраивать этот отчет. Как правило у клиента есть человек, которой "на ты" с системой, будь то внутренний консультант или специалист поддержки, для которого задача модификации отчета сведется к минимальной настройке. Я лишь хотел показать ПРАКТИЧЕСКОЕ использование обозначеннного в названии данной ветки предмета и ни в коем случае не ввязываться в обсуждение "человеко\добавьте свое-ориентированных" подходов.

[mazzy]

Цитата:

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

Если вы склонны цепляться к словам

Я целпяюсь не к словам, а к смыслу.

Цитата:

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

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

Начинается... Пошли "уточнения" в ТЗ, которые полностью меняют смысл
Даже не спрашиваю, знает ли об этом "уточнении" заказчик...

Цитата:

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

Как правило у клиента есть человек, которой "на ты" с системой, будь то внутренний консультант или специалист поддержки, для которого задача модификации отчета сведется к минимальной настройке.

А можно я себя процитирую? Обратите внимание - никаких уточнений. Только цитата:

Цитата:

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

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

Цитата:

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

Я лишь хотел показать ПРАКТИЧЕСКОЕ использование обозначеннного в названии данной ветки предмета и ни в коем случае не ввязываться в обсуждение "человеко\добавьте свое-ориентированных" подходов.

Ок, ок. Цитирую вас: "ПРАКТИЧЕСКОЕ использование ... предмета ... пользователем ... которой "на ты" с системой."

Именно это я и называю - вместо того, чтобы решать задачи пользователя, решаются чисто програмистские задачи.
См. мой комментарий №4 здесь Значение display метода по его названию

[macklakov]

Цитата:

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

Ежели есть еще какие подводные камни - поведайте, буду весьма благодарен, особенно если на проекте в аттачменте приведете примеры таких проблем.

1. Название вариантов enum-а несет в себе гораздо больше смысловой нагрузки, чем Id класса. В сложных расчетах этот параметр передается через 10-к методов, а иногда и контейнеров, в результате определить, что послужило причиной создания данного объекта и почему он являеся инстансом данного класса невозможно или очень сложно.
2. Т.к. перекрестные порушены, совсем не весело вносить существенные изменения в такой механизм. Т.к. механизм искуственно усложнен + не работают проверки сигнатур, любые изменения могут привести к неожиданным эффектам.
3. Если писатель допустил ошибку, найти ее и исправить крайне тяжело.
4. Рушится сама прадигма ООП. Такие конструкции даже на функциональное программирование не тянут, это больше похоже на использование GOTO.

Цитата:

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

Программисту - труднее(отсутствует в момент написания проверка на типы и количество аргументов и нет подсветки синтаксиса), консультанту же должно быть по барабану.

О чем и речь. Консультанту и пользователю от этого пользы никакой, разве что подтормаживает немного сильнее. Зато разработчику масса проблем. Спрашивается, для чего создаются такие "универсальные решения"?

Цитата:

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

В любом случае конечного вопроса не снимает - зачем сделана такая возможность ?

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

Цитата:

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

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

Я не против обобщений и универсальности как таковых. Я против использования классов Dict... в бизнес-логике.

[Lucky13]

2 Mazzy

Mazzy, интересно узнать ваше мнение по следующему вопросу:
Допустим есть задача: импортировать в Axapta данные, которые присылают, ну скажем, поставщики, в виде текстовых файлов. В файлах находятся практически одни и те же данные, но формат у каждого свой. Унифицировать формат невозможно.
Возможны 2 варианта решения данной задачи:
1. Программировать каждый отдельный формат отдельно с помощью Enums и switch/case
2. Создать универсальный механизм, позволяющий подстраиваться под каждый формат.

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

Какой по вашему вариант предпочтительнее?

[TasmanianDevil]

Цитата:

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

Я не против обобщений и универсальности как таковых. Я против использования классов Dict... в бизнес-логике.

Посидел, подумал, заодно по вопросам mazzy поприкидывал варианты серъезного прикладного применения - наверное все же приведенная цитата по идеологии ближе к истине. Удобности только для сервисных и девелоперских вещей получается.
В бизнес-логике, действительно, по-большому счету игра свеч вряд ли будет стоить при использовании Dict-семейства ...

[sukhanchik]

Цитата:

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

2 Mazzy

Mazzy, интересно узнать ваше мнение по следующему вопросу:
Допустим есть задача: импортировать в Axapta данные, которые присылают, ну скажем, поставщики, в виде текстовых файлов. В файлах находятся практически одни и те же данные, но формат у каждого свой. Унифицировать формат невозможно.
Возможны 2 варианта решения данной задачи:
1. Программировать каждый отдельный формат отдельно с помощью Enums и switch/case
2. Создать универсальный механизм, позволяющий подстраиваться под каждый формат.

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

Какой по вашему вариант предпочтительнее?

Посидел, подумал, почитал ветку... В общем-то я тоже стронник Dict-классов ... был до прочтения ветки.
И вот призадумался - над Вашим вопросом, отнесенным правда не ко мне.
Вот что скажу. Возможно 2 варианта решения задачи:
Вариант 1. Создаем некий конструктор импорта (та же группа определения в стандарте - только с меганастройками). Если можно обойтись стандартными группами определения - еще проще. Для каждого поставщика делаем свою группу определения, которая сохраняется в таблице. На выходе - мы имеем динамический список, который можно пополнить без программирования (лукап). В этом случае мы в принципе обходимся без программирования.
Однако этот вариант актуален - если мы готовы потратить время на настройку (и возможное программное докручивание) всего этого безобразия

Вариант 2. Форматы настолько принципиально разные - что конструктор, как общее решение - не потянет - т.е. придется писать класс. В таком случае, раз уж все равно придется работать разработчику - то модифицировать до кучи класс-со switch/case (возможно что он даже будет родительским) и добавить элемент енума - дело 5 минут.
В этом случае мы тратим время на программирование и тестирование (плюс описание) этого варианта

Есть пример в системе - когда для каждой страны существует своя проверка корректности введенного банковского счета (Классы Bank_*). Есть енум (тип банк счета) и класс Bank, который, разруливает этот енум и создает наследника.

Есть и другой пример - импорт банковских платежей. Сделан аккурат через выбор в списке класса. Если честно - то название классов - меня, разработчика, который полез первый раз изучать просто функциональность - смутило. Я еще тогда с названиями стандартных классов не был особо знаком и выбирал название - "по логике", хотя проще для меня было бы выбрать из енума.

[Lucky13]

Цитата:

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

Вариант 1. Создаем некий конструктор импорта (та же группа определения в стандарте - только с меганастройками). Если можно обойтись стандартными группами определения - еще проще. Для каждого поставщика делаем свою группу определения, которая сохраняется в таблице. На выходе - мы имеем динамический список, который можно пополнить без программирования (лукап). В этом случае мы в принципе обходимся без программирования.
Однако этот вариант актуален - если мы готовы потратить время на настройку (и возможное программное докручивание) всего этого безобразия

Вариант 2. Форматы настолько принципиально разные - что конструктор, как общее решение - не потянет - т.е. придется писать класс. В таком случае, раз уж все равно придется работать разработчику - то модифицировать до кучи класс-со switch/case (возможно что он даже будет родительским) и добавить элемент енума - дело 5 минут.
В этом случае мы тратим время на программирование и тестирование (плюс описание) этого варианта

Форматы не приниципиально разные, но их много и они постоянно добавляются. Практически каждый поставщик имеет свой, удобный ему формат. Если воспользоваться вариантом, где требуется программирование, то получим ситуацию, когда периодически будут приходить пользователи с просьбой "У нас появился новый поставщик, добавьте, пожалуйста, нам новый формат". Конечно при правильной структуре работы там не много и тестирование минимальное, но разве это правильно?
Получается, что при изменении значения параметра системы (новый поставщик) приходится менять ее структуру. По-моему неправильно "допиливать" систему при каждом появлении в ней новых данных.

[sukhanchik]

Цитата:

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

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

А я же не говорю про "допил". Есть разные варианты. У кого 5 поставщиков, у кого 25, а у кого они сотнями исчисляются
Я же сказал про конструктор (вариант 1). В этом случае - ничего "допиливать" не надо. Все делается настройками. Только конструктор главное правильно заложить. Причем - опять-таки - в зависимости от ситуации - конструктор может выродиться в группы определения.

Чем вариант с конструктором плох? Структура системы не меняется при изменения параметра системы.
Но при добавлении поставщика - ведь производятся какие-то действия? (банковский счет заводится, условия оплаты и прочая информация). Этот перечень расширяется на добавление группы определения (или ее аналога)

У Вас другое мнение?

[Владимир Максимов]

Цитата:

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

Допустим есть задача: импортировать в Axapta данные, которые присылают, ну скажем, поставщики, в виде текстовых файлов. В файлах находятся практически одни и те же данные, но формат у каждого свой. Унифицировать формат невозможно.
Возможны 2 варианта решения данной задачи:
1. Программировать каждый отдельный формат отдельно с помощью Enums и switch/case
2. Создать универсальный механизм, позволяющий подстраиваться под каждый формат.

Можно я тоже встряну?

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

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

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

В принципе, есть еще вариант. Заставить поставщиков присылать файлы в определенном формате. Но тут вопрос в том, кто больше заинтересован в этой информации. Вы или поставщик.

Строго говоря, разговоры "вообще" обычно ничем хорошим не кончаются. Нужно знать конкретную ситуацию. Слишком много "но" и "если" влияющих на выбор того или иного способа решения.

[Lucky13]

Цитата:

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

Чем вариант с конструктором плох? Структура системы не меняется при изменения параметра системы.
Но при добавлении поставщика - ведь производятся какие-то действия? (банковский счет заводится, условия оплаты и прочая информация). Этот перечень расширяется на добавление группы определения (или ее аналога)

У Вас другое мнение?

Я полностью за вариант конструктора. Меня заинтересовало вот что:

Цитата:

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

Ваше описание основано на одном предположении

Вы всерьез уверены, что пользователь СМОЖЕТ скомпоновать запрос? Тем более в форме, подобной SysQueryForm?
По-моему, вы привели замечательный пример... хм... не "человекоориентированного" подхода

Да, я знаю, что такие пользователи есть. Но их единицы. Мы рассказываем о такой возможности SysQueryForm всем пользователям. Но пользуются этой фичей единицы. И то только если консультант создаст запрос и сохранит его в списке используемых запросов.

Итак, повторюсь: вы делаете, делаете некую супер-фичу. Ваша супер-фича основывается на том, что пользователь будет формировать запрос.
Вы всерьез уверены, что пользователь СМОЖЕТ скомпоновать запрос?

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

[Lucky13]

Цитата:

Сообщение от Владимир Максимов

Можно я тоже встряну?

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

Настройки будет делать пользователь. Достаточно научить одного самого умного.

Цитата:

Сообщение от Владимир Максимов

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

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

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

Цитата:

Сообщение от Владимир Максимов

В принципе, есть еще вариант. Заставить поставщиков присылать файлы в определенном формате. Но тут вопрос в том, кто больше заинтересован в этой информации. Вы или поставщик.

Строго говоря, разговоры "вообще" обычно ничем хорошим не кончаются. Нужно знать конкретную ситуацию. Слишком много "но" и "если" влияющих на выбор того или иного способа решения.

Дело не в конкретной задаче, она уже давно решена. Хочелось узнать какие есть еще варианты ее решения, кроме выше перечисленных, учитывая "человекоориентированный подход"

[mazzy]

Цитата:

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

Я не против обобщений и универсальности как таковых. Я против использования классов Dict... в бизнес-логике.

О! Полностью согласен.

Цитата:

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

Mazzy, интересно узнать ваше мнение по следующему вопросу:
Допустим есть задача: импортировать в Axapta данные, которые присылают, ну скажем, поставщики, в виде текстовых файлов. В файлах находятся практически одни и те же данные, но формат у каждого свой. Унифицировать формат невозможно.

Уже ответили. Я согласен с уже высказавшимися ораторами.

Я только хотелось бы обратить ваше внимание, что требования: "импортировать в Axapta данные", "Унифицировать формат невозможно" взаимоисключающие.

Либо вы хоть как-то унифицируете (возможно не на 100%), либо каждый раз будете изобретать отдельный механизм. Первые шаги по унификации вы уже сделали, оговорившись, что формат являтся текстовым. Идите дальше. Определите обязательные поля (ИНН?, телефоны? адреса? наименование? артикул? артикул поставщика или ваш? Количество? Единицы измерения?)
Далее определите отношения 1:1, 1:N, N:N между полями.
Далее определите правила валидации. Правила, которые возвращают Истина, если данные валидны.

Видите, как много унифицировали?

Далее начинается положение полей в файле, в строке. Относительное и/или абсолютное. Скорее всего, под "унифицировать формат невозможно" вы имели в виду всего лишь то, что поля могут иметь разное положение. Но все равно вы ошибаетесь. Разберитесь и поймите как эти данные читают ЛЮДИ на вашем предприятии. Ведь они читают, не так ли? Т.е. формат не может быть абсолютно произвольным? Все равно существуют какие-то инварианты (извините за использование термина).

Так вот. Первая задача выделить инварианты и дать возможность пользователям настраивать переменные параметры на том языке, на котором говорят пользователи. Но ни в коем случае не делать настройки на языке display-методов или callObject'ов и другой программисткой фигни.

Если же вы сознательно выбираете машиноориентированный подход, то не мучайтесь и юзайте штатный механизм импорта из текстовых файлов, как здесь уже посоветовали. http://axapta.mazzy.ru/lib/import/

Цитата:

Возможны 2 варианта решения данной задачи:
1. Программировать каждый отдельный формат отдельно с помощью Enums и switch/case
2. Создать универсальный механизм, позволяющий подстраиваться под каждый формат.

Есть еще варианты:
3. юзать импорт
4. переносить данные макросами http://axapta.mazzy.ru/lib/easyimport/
5. не импортировать, а заставить набивать в вашу систему ваших пользователей
6. не импортировать, а заставить набивать в вашу систему ваших поставщиков
7. не импортировать, а сделать сервис и опубликовать его, чтобы поставщики сами программировали общение с вашим сервисом
8. другие варианты

Главное - не зашоривать сознание

Цитата:

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

Какой по вашему вариант предпочтительнее?

Зависит от: если у вас нет пользователей с достаточной квалификаией, то просто каждый раз программируйте простое решение. Только перед программированием выделите инварианты и создайте нормальный, расширяемый базовый класс. Ни в коем случае не DictTable

Цитата:

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

Вариант 1. Создаем некий конструктор импорта (та же группа определения в стандарте - только с меганастройками). Если можно обойтись стандартными группами определения - еще проще. Для каждого поставщика делаем свою группу определения, которая сохраняется в таблице. На выходе - мы имеем динамический список, который можно пополнить без программирования (лукап). В этом случае мы в принципе обходимся без программирования.
Однако этот вариант актуален - если мы готовы потратить время на настройку (и возможное программное докручивание) всего этого безобразия

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

Цитата:

Вариант 2. Форматы настолько принципиально разные - что конструктор, как общее решение - не потянет - т.е. придется писать класс. В таком случае, раз уж все равно придется работать разработчику - то модифицировать до кучи класс-со switch/case (возможно что он даже будет родительским) и добавить элемент енума - дело 5 минут.
В этом случае мы тратим время на программирование и тестирование (плюс описание) этого варианта

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

Цитата:

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

Форматы не приниципиально разные, но их много и они постоянно добавляются. Практически каждый поставщик имеет свой, удобный ему формат. Если воспользоваться вариантом, где требуется программирование, то получим ситуацию, когда периодически будут приходить пользователи с просьбой "У нас появился новый поставщик, добавьте, пожалуйста, нам новый формат".

Используя настройки типа "выбор dispaly-метода" или "настройка групп определения" вы не решите эту проблему. Все равно будут приходить к программисту и говорить - настрой пожалуйста

Цитата:

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

Конечно при правильной структуре работы там не много и тестирование минимальное, но разве это правильно?

А почему нет, если другими решения все равно может настраивать только разработчик?

Цитата:

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

Получается, что при изменении значения параметра системы (новый поставщик) приходится менять ее структуру. По-моему неправильно "допиливать" систему при каждом появлении в ней новых данных.

Неправильная логика.
Появляется не новый поставщик, а новый формат данных.
Нужен новый драйвер.

Тут самое главное - без фанатизма.

Человекоориентированный подход подразумевает, что программа ждет от него данных на понятном ему языке, что человек понимает что надо делать. Поэтому некоторые понятные человеку параметры вполне можно делать параметрами. Например, "начать импорт со строки с номером", "параметр начинается в колонке с номером". Но ни в коем случае нельзя давать человеку выбрать один из display-методов, ни в коем случае нельзя делать бесконечное число галочек и т.п.

Цитата:

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

Я же сказал про конструктор (вариант 1). В этом случае - ничего "допиливать" не надо. Все делается настройками.

ВСЕ - нехорошее слово.
Как только появляется слово ВСЕ - жди логической ошибки.

Цитата:

Сообщение от Владимир Максимов

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

Абсолютно согласен.

Цитата:

Сообщение от Владимир Максимов

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

Абсолютно согласен.

Цитата:

Сообщение от Владимир Максимов

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

Золотые слова!

Цитата:

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

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

А зачем обходится?
Вопрос так, не стоит по-моему.

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

Как сказал macklakov: "Я не против обобщений и универсальности как таковых. Я против использования классов Dict... в бизнес-логике."

Цитата:

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

Дело не в конкретной задаче, она уже давно решена. Хочелось узнать какие есть еще варианты ее решения, кроме выше перечисленных, учитывая "человекоориентированный подход"

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

[Lucky13]

Цитата:

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

Axapta данные", "Унифицировать формат невозможно" взаимоисключающие.

Я имел в виду что невозможно сделать так, чтобы форматы были на 100% одинаковыми. Во всем остальном согласен.

Цитата:

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

Далее начинается положение полей в файле, в строке. Относительное и/или абсолютное. Скорее всего, под "унифицировать формат невозможно" вы имели в виду всего лишь то, что поля могут иметь разное положение. Но все равно вы ошибаетесь. Разберитесь и поймите как эти данные читают ЛЮДИ на вашем предприятии. Ведь они читают, не так ли? Т.е. формат не может быть абсолютно произвольным? Все равно существуют какие-то инварианты (извините за использование термина).

Не только положение. Инициализация поля определенным значением, при определенных условиях. Например, дата поставки равна текущей дате, если такого поля в файле нет (условия и значения определяются спецификой предметной области и наперед известны), удаление определенных символов из определенных полей, добавление суффиксов и префиксов. Согласен, это и есть унификация пусть не на 100%.

Цитата:

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

Разберитесь и поймите как эти данные читают ЛЮДИ на вашем предприятии. Ведь они читают, не так ли?

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

Цитата:

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

Так вот. Первая задача выделить инварианты и дать возможность пользователям настраивать переменные параметры на том языке, на котором говорят пользователи. Но ни в коем случае не делать настройки на языке display-методов или callObject'ов и другой программисткой фигни.

Так и сделано. Пользователь не выбирает таблицы и поля по их названию в АОТ, но он выбирает по их label в какое поле загружать те или иные данные. Пользователю это не заметно, но в коде используются классы DictTable/DictField. Это я вот к чему:

Цитата:

Сообщение от mazzy;

Вы всерьез уверены, что пользователь СМОЖЕТ скомпоновать запрос? Тем более в форме, подобной SysQueryForm?
По-моему, вы привели замечательный пример... хм... не "человекоориентированного" подхода

В общем мнение понял, спасибо, но не со всем согласен. Действительно не каждый пользователь может разобраться как настраивать импорт, но ведь задачу программист не сам придумывает. Какая постановка задачи, таково должно быть и решение. Если задача ставится так: хочу чтобы данные от поставщиков появились в Аксапте. То наверное и не стоит делать сложных универсальных механизмов, с кучей галочек и т.п. - все равно никто не будет настраивать. А если задача ставится так: Хочу механизм, который бы позволил импортировать данные, подстраиваться под формат поставщика, чтобы я мог сам все настроить, форматы бывают такие, такие и еще вот такие. Вот тогда есть смысл унифицировать форматы (насколько это возможно) и делать конструктор. Раз человек смог поставить такую задачу, значит он понимает о чем говорит и значит сможет настроить. Как замечено выше - пользователь должен работать с интерфейсом на понятном ему языке, но пользователи-то бывают разные. Конечно постановок задач по первому типу во много раз больше, чем по второму, но и такое тоже может быть. Не стоит говорить, что все пользователи не поймут, не разберутся. Как там говорится про слово ВСЕ

[mazzy]

Цитата:

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

В общем мнение понял, спасибо, но не со всем согласен.

И это классно!