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

[S.Kuskov]

Он сказал: "Поехали!" и взмахнул рукой..

Цитата:

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

Это нужно не для всех журналов, а только Проводки,Приб\Убытки\Перенос+еще 2.(т.е.хорошо бы в этом методе иметь установленный параметр с формы, чтобы не нести этот код в метод таблицы.)

Тащить ничего никуда не нужно. Этот параметр доступен через this.JournalType.

Цитата:

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

При update в Trans нужно отработать еще ряд методов по другим таблицам

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

Цитата:

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

посмотрите update Transdate при изменении даты в Grid

Да, возможно с update_recordset я погоричичлся. Можно добавить как минимум

while select InventJournalTrans where InventJournalTrans.JournalId == this.JournalId inventJournalTrans.inventMovement().journalSetTransDate();

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

Цитата:

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

Кроме того, update на Trans в нашей реализации идет с параметром(но он не selectforupdate)

Не совсем вас понимаю. Возможно прийдётся полностью отказаться от update_recordset и использовать явный вызов update с дополнительным параметром.[/QUOTE]

Цитата:

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

прямой update этой даты в Table не находит своего своего отражения на форме (возможно нужно где-то (?) вставить research() на DS формы)

Возможно. Это нормально.

Цитата:

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

нужен еще и диалог по изменению даты(где его затеять, тогда?), вдруг это кто то сел на клавиатуру.

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

[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

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

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

[Владимир Максимов]

Цитата:

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

Журналы InvetJournalTable+InvetJournalTrans(Строки). Нужно, чтобы строки одного журнала имели одну дату. Для этого решили эту дату внести в Table (уже неверно). И при изменении поля клиентом в Table необходимо поменять дату и в строках. Решил: в validate этого поля на DS в Table тут же спросить клиента и при ДА заменить дату и в Table и в Trans. Все работает, но: если клиенту придет в голову нажать Esc вместо Save и там отказаться от модификации , то даты разъедутся. Вот и вся проблема(мелочи я опускаю).

Ошибка не в том, что Вы создали общую дату в шапке документа (это как раз нормально), а в том, что Вы выполняете некую модификацию в Validate(), что принципиально неверно!

Validate() не должен ничего изменять. Его цель - это всего-лишь верификация. Контроль корректности внесенных изменений.

Собственно, отсюда и Ваши проблемы. Я уже указал, меняйте в событии write() на DataSource-формы или (как уже сказали) в табличных методах update(). Т.е. в тех методах, которые, собственно, и предназначены для модификации.

Другая Ваша ошибка - это диалог с пользователем.

Практика показывает, что пользователи диалоги не читают! У них другая задача. Им надо ввести документ. Срочно! Еще вчера! Если интерфейс позволяет это сделать, нажав кнопку "Да"/"Нет", то они и будут нажимать кнопки не обращая внимания на текст. Тем более, в Вашем случае совершенно не важно, какую кнопку они нажмут.

Вы должны жестко "прошить" правила, когда измененная дата приводит к изменению даты во всех строках журнала. Возможно, создать дополнительные настройки или настроечные таблицы. Никакого диалога с пользователем быть не должно!

[pwp]

Цитата:

Сообщение от Владимир Максимов

Ошибка не в том, что Вы создали общую дату в шапке документа (это как раз нормально), а в том, что Вы выполняете некую модификацию в Validate(), что принципиально неверно!!
Validate() не должен ничего изменять. Его цель - это всего-лишь верификация. Контроль корректности внесенных изменений.

Возможно, Вы правы.

Цитата:

Сообщение от Владимир Максимов

Другая Ваша ошибка - это диалог с пользователем.
Практика показывает, что пользователи диалоги не читают! У них другая задача. Им надо ввести документ. Срочно! Еще вчера! Если интерфейс позволяет это сделать, нажав кнопку "Да"/"Нет", то они и будут нажимать кнопки не обращая внимания на текст. Тем более, в Вашем случае совершенно не важно, какую кнопку они нажмут.
Вы должны жестко "прошить" правила, когда измененная дата приводит к изменению даты во всех строках журнала. Возможно, создать дополнительные настройки или настроечные таблицы. Никакого диалога с пользователем быть не должно!

Здесь есть возражения. То, что не читают-верно и жмут подряд. Но сам факт вопроса должен быть, иначе Вам скажут, что не хотели менять дату, а она сама поменялась. Просто по умолчанию должно все отработать по норме.
"Прошить" правила...без диалога вряд ли получится, клиент ведь может ввести и неправильную дату(например 01.01.2010 вместо 05.01.2010), которую по таблицам не отследить, И вообще нужно было изменение даты (редкая операция) сажать на кнопку, а не вытаскивать это из Грид.

[Владимир Максимов]

Цитата:

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

То, что не читают-верно и жмут подряд. Но сам факт вопроса должен быть, иначе Вам скажут, что не хотели менять дату, а она сама поменялась. Просто по умолчанию должно все отработать по норме.
"Прошить" правила...без диалога вряд ли получится, клиент ведь может ввести и неправильную дату(например 01.01.2010 вместо 05.01.2010), которую по таблицам не отследить,

Вы уж определитесь. Если согласны с тем, что "не читают", то какая разница, какой именно вопрос Вы зададите? Все-равно ведь не прочитают

Если Вы считает, что факт наличия вопроса как-то поможет Вам при "разборе полетов", то не обольщайтесь. Возможно, перед руководством Вы и сможете себе обезопасить, но данные-то все-равно получатся кривыми. Задавали Вы вопрос или нет. Ведь не читают же! Да и исправлять-то кому? По любому, лишние проблемы для СЕБЯ!

Здесь возможен только отказ в изменении. Но никаких диалогов!

Цитата:

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

И вообще нужно было изменение даты (редкая операция) сажать на кнопку, а не вытаскивать это из Грид.

Ну, и настаивайте на этом решении. Объясните консультанту всю глубину его заблуждений

[S.Kuskov]

Цитата:

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

И вообще нужно было изменение даты (редкая операция) сажать на кнопку, а не вытаскивать это из Грид.

Кстати, никто не мешает вам сделать это. Тем самым вы решите свою проблему централизации источника изменений. Но вопросу совместимости вашего кода по смене даты со стандартным кодом стоит уделить максимум внимания. Я бы сказал встаёт вопрос не где делать изменения, а как их делать.

[pwp]

Цитата:

Сообщение от Владимир Максимов

Вы уж определитесь. Если согласны с тем, что "не читают", то какая разница, какой именно вопрос Вы зададите? Все-равно ведь не прочитают
..........................
Здесь возможен только отказ в изменении. Но никаких диалогов!

В общем это вопрос спорный и иделогический......Насчет диалога Вы меня не убедили.

Цитата:

Сообщение от Владимир Максимов

Ну, и настаивайте на этом решении. Объясните консультанту всю глубину его заблуждений

Я попробую, конечно, но нет уверенности, что будут слушать....Думаю, есть аксиомы, которые нарушать не следует. В частности - единственность источника данных- а она здесь нарушена - отсюда и проблемы. Причина в этом.Правда, никто из принявших участие, меня пока не поддержал на эту тему.

Цитата:

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

Кстати, никто не мешает вам сделать это. Тем самым вы решите свою проблему централизации источника изменений. Но вопросу совместимости вашего кода по смене даты со стандартным кодом стоит уделить максимум внимания. Я бы сказал встаёт вопрос не где делать изменения, а как их делать.

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