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

[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

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

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