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

[Lucky13]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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