Управление изменением записей на форме.

[pwp]

Цитата:

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

Если есть много нюансов, которые не хочется городить в методе update(), ................... на датасорсе.

Да у меня сейчас вроде так и сделано, только вместо класса я сделал метод в классе JournalFormTable. Но стоит требование конса делать это не по кнопке, а по редактированию даты(я этого не поддерживаю) отсюда проблема с ESC (см.выше)

[S.Kuskov]

Цитата:

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

Да у меня сейчас вроде так и сделано...

Возможно действительно не стоит так серьёзно заморачиваться с синхронизацией дат в шапке и строках. А просто учесть возможность появления разсогласованных данных. И Добавить соответствующую проверку перед разноской, что мол даты в строках и шапке не совпадают. Поправить? Да. Нет.

[pwp]

Цитата:

Сообщение от S.Kuskov

Он сказал: "Поехали!" и взмахнул рукой..
Тащить ничего никуда не нужно. Этот параметр доступен через this.JournalType.

Это да, но перебор придется вставить, что не очень смотрится в update на Table...

Цитата:

Сообщение от S.Kuskov

Отрабатывайте. Перекрывайте аналогичным образом InventJournalTrans.update() и отрабатывайте.

В порядке ликбеза, это уже на DS формы ?

Цитата:

Сообщение от S.Kuskov

И да, есть ещё такие классы как InventJournalData и InventJournalTransData. Вам никто не мешает использовать и их.

Только в методе update на таблице Table как к ним подобраться ?

Цитата:

Сообщение от S.Kuskov

Не понял вас. Нужен диалог который сможет влиять на что? изменение даты в InventJournalTable? Ну так это совершенно другая задача. Она никак не связана с последствиями смены этой даты. Вызывайте его например в методе validateWrite источника данных InentJournalTable.

Ну как же так, смена даты клиентом первооснова и причина всех дальнейших прыжков. Только нужно обеспечить защиту от случайного изменения=подтверждение.

Цитата:

Сообщение от S.Kuskov

Возможно действительно не стоит так серьёзно заморачиваться с синхронизацией дат в шапке и строках. А просто учесть возможность появления разсогласованных данных. И Добавить соответствующую проверку перед разноской, что мол даты в строках и шапке не совпадают. Поправить? Да. Нет.

Не совсем сие красиво, IMHO. Мало того, что при входе в строки имеет разность дат+разносить возможно будет другой, кто не в курсе всего...Да и отложить это на разноску ну ничем не отличается от первичной проблемы. Спасибо за анализ всей проблемы.

[S.Kuskov]

Цитата:

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

Это да, но перебор придется вставить, что не очень смотрится в update на Table...

Рефакторингом займётесь когда всё заработает.

Цитата:

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

В порядке ликбеза, это уже на DS формы ?

Неа.Идя в том чтобы по максимому изолироваться от интерфейса пользователя. В данном случае таблицы содержат всю необходимую для работы информацию. Так зачем же логику переносить в методы источника данных какой-то конкретной формы.

Цитата:

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

Только в методе update на таблице Table как к ним подобраться ?

InventJournalData = JournalTableData::construct(this);
InventJournalTransData = new JournalTransData(InventJournalTrans, InventJournalData);

Цитата:

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

Ну как же так, смена даты клиентом первооснова и причина всех дальнейших прыжков. Только нужно обеспечить защиту от случайного изменения=подтверждение.

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