Посоветуйте, пожалуйста, вариант реализации для объектов, состоящих из нескольких документов

[Gandliar]

Всем привет!

Есть документ договора
К документу договора есть список изделий (встроенная вьюшка)
Изделия состоят из модулей (встроенная вьюшка)
У модуля есть цена

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

Прошу совета по реализации.

 

[garrick]

Клиент, XPages?

 

[NetWood]

документ договора и/или документ изделия могут быть уже открыты этим же пользователем в соседней вкладке, и их надо как то обновить.

По мне так речь идет о элементарной дисциплине использования интерфейса, адекватности юзеров и протокола администрирования процесса.

В случае рецидива формировать всегда договор заново, с временем жизни на открытие, а при попытке че нить с ним сделать проверять исходники на время подписи. И это может быть долго, медленно...
План Б; если основной документ открыт, то в исходники изменения внести нельзя.

 

[Gandliar]

Клиент, XPages?

Клиент

 

[garrick]

Я бы сделал так - при открытии документа запоминать текущую дату-время, при сохранении проверять дату-время последнего изменения связанных документов или достаточно самого основного документа если он меняется в бэкграунде агентом. Если видим что связанные документы/основной документ изменились после открытия основного документа, сообщать пользователю что он дурак сохранение невозможно и ему надо самостоятельно переоткрыть документ и начать всё сначала. Сначала будут они будут ворчать/ругаться, потом самоорганизуются и всё стабилизируется, даже научатся "конфликты" не создавать в базе.

 

[NetWood]

ворчать/ругаться, потом самоорганизуются и всё стабилизируется, даже научатся "конфликты" не создавать в базе.

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

Здесь также. Попытка изобретения велосипеда. Это вопрос к руководству, а не к процессу.

 

[garrick]

Но это никого не смущает - счет актуален на дату-время цены

Тоже вариант, но это к программированию не имеет никакого отношения. Впрочем, как и большинство проблем автоматизации бизнес-процессов.

 

[VladSh]

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

Мы когда-то делали такое (я был против, и уговаривал шефа не делать этого). Вбухали полтора года, а выхлоп, как я и предполагал, был равен нулю. Очень неудобно это, т.к. задача не для Lotus.

Но если уж делать, то собственная система запросов-"транзакций" + блокировки документов. При выполнении запроса сохраняем в нём UNID'ы документов, которые не смогли быть сохранены, при повторной обработке запроса пытаемся выполнить действие для этих документов и сохранить. Либо вообще делать "атомарные" запросы - 1 запрос на изменение одного документа. Ну и блокировки конечно должны работать HardLock + SoftLock.

 

[Gandliar]

Вот думаю использовать метод doc.Isuidocopen, для проверки, открыт документ документ в UI или нет, для текущего пользователя.

Выяснил следующую закономерность:
Если
1. в форме объявить глобальную переменную doc as NotesDocument
2. в Postopen присвоить set doc = Source.Document
3. Получить в другом скрипте (например в агенте) документ set doc=db.Getdocumentbyunid(unid)
то
свойство doc.Isuidocopen покажет открыт документ в UI или нет

Причем, если doc изначально получен из вида, то надо сделать Delete doc, а затем set doc=db.Getdocumentbyunid(unid)

Есть у меня ощущение, что когда из из uidoc создается doc в памяти и живет в ней, то db.Getdocumentbyunid(unid) получает как раз ссылку на этот док в памяти.

Таким образом можно узнать открыт ли uidoc для дока и его переоткрыть.

Что думаете об этом? Какие подводные камни?

 

[lmike]

Вот думаю использовать метод doc.Isuidocopen, для проверки, открыт документ документ в UI или нет, для текущего пользователя.

Выяснил следующую закономерность:
Если
1. в форме объявить глобальную переменную doc as NotesDocument
2. в Postopen присвоить set doc = Source.Document
3. Получить в другом скрипте (например в агенте) документ set doc=db.Getdocumentbyunid(unid)
то
свойство doc.Isuidocopen покажет открыт документ в UI или нет

Причем, если doc изначально получен из вида, то надо сделать Delete doc, а затем set doc=db.Getdocumentbyunid(unid)

Есть у меня ощущение, что когда из из uidoc создается doc в памяти и живет в ней, то db.Getdocumentbyunid(unid) получает как раз ссылку на этот док в памяти.

Таким образом можно узнать открыт ли uidoc для дока и его переоткрыть.

Что думаете об этом? Какие подводные камни?

получение малевича или сообщения об удалении объекта - реальный кейс при игре с уйнёй (UI)
как-то делал на классах в привязки к Event, регистрировал классы (цепочку) в постопен, так ещё и подформы перехватываются и код в единой либе, а не размазан по форме
НО, повторю - все игрища с уйнёй рано или поздно начинают козлить, ну вот не сделали нормальное управление (и уже не сделают)