navision(4) - нелепое поведение логики фиксации изменений

Почтенные, объясните плиз, что за нелепое поведение логики фиксации
изменений в навижн?
Пользовтель заполняет форму (изменяет запись), затем происходит попытка фиксации
записи, и в случае неудачи (валидации значений и т.д.) отменяется весь пользовательский
ввод (все изменения записи)? Насколько я понимаю, изменение значения какого-либо
поля само по себе не вызывает попытки фиксации записи; за что же так жестоко карать,
убивать все изменения полей в форме при неудачной попытке фиксации записи?
Может быть, у меня неверное представление, или таким поведением можно как-то
управлять - выключить такой вот откат изменений данных на форме?
Это же кошмар какой-то...я пока даже не очень представляю, как при такой реализации
правильно реализовать валидацию данных без утраты пользовательского ввода...
НАВ 4, но утверждают, что и в следующих версиях всё то же самое.


Пресветлый старец Фалоим Московскый.
тимтэг:некоммерческое товарищество "Напиджак",
издательство "Московский Пустомолец"

Remarks
http://msdn.microsoft.com/en-us/library/dd355319

This trigger executes before the default modify behavior is executed. If an error occurs in the
trigger code, the record changes are canceled.

We recommend that you do not include code that can stop the user from recording a change in
the OnModify trigger on a table. For example, do not include code for displaying error messages.
If a user has previously changed the contents of some fields in a record, then these changes
must always be accepted by the system.

ЗЫ: почему-то вспомнилось выражение: "парламент-не место для дискуссий".

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

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

МистерШоу
ЗЫ: почему-то вспомнилось выражение: "парламент-не место для дискуссий".

OnValidate вместо OnModify

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

+100

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

да ладно. Это на фоне чего?

iscrafm
МистерШоу ЗЫ: почему-то вспомнилось выражение: "парламент-не место для дискуссий". OnValidate вместо OnModify

? я в описании не увидел валидэйт уровня записи таблицы или формы.

Tables have the following triggers.
Table trigger Executes when
OnInsert Trigger
A new record is inserted into the table.
OnModify Trigger
A record in the table is modified.
OnDelete Trigger
A record in the table is deleted.
OnRename Trigger
A record is modified in a primary key field

А вот этот триггер:
OnBeforePutRecord Trigger
Executed before a record is saved.
Applies To Forms
If there is an error in the trigger code, the form is closed.

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

шутю - понятно, что каждая система имеет право на фичу,
а кто не доволен -чемодан/вокзал/ивропа. То есть, десятьтыр/Селезнёвка/1с :)

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

кстати не только NAV. На клиенте проверяются разве что уж совсем банальные вещи, вроде ввода буквы в номер, в котором ее не может быть по умолчанию. А в остальном -> сохранение, на сервере проверка, если все нормально, то учет и т.п.. Если нет - повторная корректировка

МистерШоу
? я в описании не увидел валидэйт уровня записи таблицы или формы.

это уровень Field. Вообще, чуть выше один из принципов описан. Сохранять все, а вот учитывать только валидное.

iscrafm
ДжекНепотрошитель с точки зрения пользовательского интерфейса, система ужасна настолько, насколько это в принципе может быть возможно для GUI-приложений да ладно. Это на фоне чего?

скепсис понятен, но фейс конечно типичное УГ больших серьезных систем.
Как и в OEBS - функционально, однообразно, масштабируемо, скучно до зевоты.
Фейс, кажущийся кошмаром после домашнего уюта уникальных форм самопальных систем,
где заботливый карманный прог использовал 256 цветов, кучу полезных кнопок,
закладок и т.д. :)
Вот 1С заметил в бухгалтере женщину, не зря в заставке на фоне гроссбухов
эта романтичная розочка - это вообще, имхо, мегагениальное
маркетинговое проникновение в подсознание, "этим только и берут они"(с).