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

[sukhanchik]

Цитата:

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

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

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

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

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

[Lucky13]

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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

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