Здравствуйте, Sinclair, Вы писали:

S>2. Есть некоторый стандартный интерфейс взаимодействия, доступный для понужания IT-отделом заказчика. В таком случае как правило пишется PDF страниц на шестьдесят, и на все вопросы типа "а можно мы вместо данных сюда какое-нть г-цо засунем?" отвечается "можно, но в соответствии с PDF". В самом крайнем случае можно позволить некоторую настройку этого интерфейса, типа реакция на неконсистентные данные — игнор/мэйл-ворнинг/роллбэк.
Если есть готовый продукт, и его продают всем подряд, тогда так и бывает. А если продукт еще только пишется, и feedback оказывает на него огромное влияние, то никакого жесткого прописанного в PDF стандарта нет. Если он все же есть, то это как раз и есть тот ответ на мой вопрос, когда мы говорим: "нет, ребята, так нельзя, а можно только вот так". Но тогда заказчик может начать проявлять недовольство.

S>Т.е. вместо набора диалогов
S>

...
S>

S>который требует много лишних действий, сделать вот так:
S>

...
S>

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

S>Нужно помнить, что логика модели не всегда совпадает с логикой пользователя.
Бога ради! Но здесь эффективность действий пользователя можно сохранить без ущерба для логичности модели. Однако заказчику лень идти на такие усилия, им хочется, чтобы их часть работы была очень мала и проста, а как это отразится на логике модели (которая попросту станет ни с того ни с сего более запутанной), им все равно.

Что скажете?

Slicer