Ответы во встроенном представлении

  • Автор темы LuMee
  • Дата начала
L

LuMee

Есть форма, на ней встроенная вьюха. Стоит задача отобразить в этой вьюхе только ответы на данный документ.
Пытался сделать просто вьюху, в которую отбираются только нужные ответные документы и группируются по $REF, однако, как я понял, лотусу нужно, чтобы во вьюхе обязательно были обычные документы (просто так ответы не покажет).
Наверняка есть какое-то решение (скорее всего - простое), но никак не придумаю ;)
 
L

Lexa-xa

Может не убрал галочку Show response documents in a hierarchy
 
L

LuMee

Мда, все-таки конец рабочего дня очень тяжело сказывается на уровне интеллекта ;) И впрямь про галочку забыл :)
Остался лишь последний вопрос: а как бы еще в этой встроенной вьюхе action'ы отобразить? Или в 5-ке такого не поддерживается?
 
L

Lexa-xa

Остался лишь последний вопрос: а как бы еще в этой встроенной вьюхе action'ы отобразить? Или в 5-ке такого не поддерживается?

На счет 5-ки не знаю, но опять-таки поставь галку на свойствах Embedded View \ Display \ Show action bar
 
L

LuMee

Такого нет.. ну ладно, кнопочками как-нибудь обойдемся ;)
Вот еще такой вопрос - можно ли получить программный доступ ко встроенной вьюхе, а именно узнать выбранный в данный момент документ?
 
E

Elena Nefedova

Маленькое примечание к выводу панели действий встроенного вида:
Агенты, вызываемые из встроенной в форму вьюхи, не должны использовать db.UnprocessedDocuments.
Вместо этого можно обработать коллекцию NotesUIview.Documents и свойство NotesUIview.CaretNoteID .
После обработки коллекции необходимо снять выделение документов: NotesUIview.DeselectAll .
 
L

LuMee

Факт интересный, однако панели действий в R5 все равно нет... А вот вопрос про определение выбранного документа по-прежнему остается открытым.
На данный момент попробовал его подцепить с помощью NotesUIWorkspace.CurrentView - не получилось (Object variable not set). С нетерпением жду советов ;)
 

Andre

Green Team
29.07.2004
114
1
BIT
2
Для 5 когда-то делал фокус с получением одного выделенного документа в embedded view используя совет Dmitry Akulov

Суть:
Например есть 2 фрейма - MainDoc и EmbViewSelectedDoc.
Основной документ открывается во фрейме MainDoc - раздел AutoFrame с 3-й закладки формы
Для embView указываем фрейм EmbViewSelectedDoc - указываем Frame для single и double click на 1-й закладке свойств EmbeddedView

Далее кнопка "Изменить" на форме основного документа с кодом, которая в случае если есть выделенный документ то передает его UNID (или то поле которое необходимо для последующей идентификации документа или значение поля которое просто нужно получить из выделенного в embedded view документа - нужное подчеркнуть ;) ) в поле embViewSelDocUNID основного документа и кликает кнопку для обработки (в моем случае это hotspotBtn c Name = CorrectSelected - последняя закладка свойств Button - Html Tag Name). Получить документ по его идентификатору уже дело техники :)

Примерный код для кнопки изменить:
if (window.parent.frames[1] !=null )
{
var fRight=window.parent.frames[1].document.forms[0]
var fLeft=window.parent.frames[0].document.forms[0]
fLeft.embViewSelDocUNID.value=fRight.UNID.value
window.document.forms[0].CorrectSelected.click()
}else
{alert("Не выделен документ.")}

Из минусов - документ выделенный в embView каждый раз при навигации по embView открывается во фрейме EmbViewSelectedDoc. Посему применение не всегда является оправданным.
Получить можно только один выделенный в embView документ.
Ну и еще наверное минусы и грабли тоже есть ...

Вроде ничего не забыл.
Удачи

З.Ы. В качестве варианта попроще - можно попробовать отрабатывать событие view QueryOpenDocument с записью идентификатора документа в Notes.ini или еще куда и в скрипте потом читая эту запись, но это только по двойному клику на выделенном документе, что далеко не всегда является допустимым и тем более далеко не очевидно для пользователя.
 
L

LuMee

З.Ы. В качестве варианта попроще - можно попробовать отрабатывать событие view QueryOpenDocument с записью идентификатора документа в Notes.ini или еще куда и в скрипте потом читая эту запись, но это только по двойному клику на выделенном документе, что далеко не всегда является допустимым и тем более далеко не очевидно для пользователя.
Ну да, у меня была похожая мысль - на QueryOpen повесить код, который бы куда нибудь сохранял ссылку на NotesUIView встроенной вьюхи... Вот только так и не придумал, как и куда его бы засунуть :)
 

Andre

Green Team
29.07.2004
114
1
BIT
2
Неа, имхо сохранить ссылку на NotesUIView не выйдет никак. Индусы постарались :)
Приходится извращаться по всякому.
 
L

LuMee

Неа, имхо сохранить ссылку на NotesUIView не выйдет никак. Индусы постарались :(
Приходится извращаться по всякому.
А жалко.. Вообще, странно даже - вроде бы вполне очевидна необходимость узнавать, что выбрано во встроенной вьюхе, а не предусмотрено...
Ну да ладно, с фреймами даже красивше получилось, правда, теперь возникает такая проблема: мне изначально хотелось, чтобы документ, выбранный во встроенной вьюхе, можно было не просто пощупать на предмет тех или иных полей, но еще и, скажем, удалить. На JavaScript это, как я понимаю, не пройдет. Можно там будет, например, кнопочку невидимую на форме создать с нужным кодом, а потом ее JavaScript'ово кликнуть?
 

Andre

Green Team
29.07.2004
114
1
BIT
2
Конечно очевидна необходимость, но IBM думает по другому.
В 6 и 7 картина по работе с embedded view не сильно отличается, исключая возможность вывода actionBar embedded view и доступом к документам выделенным во view, но только для view - точнее на уровне view. Получить на форме эти же документы - все те же пляски с бубном.
Для 6 и выше где то в закромах есть С Api код по получению коллекции выделенных документов, но оно не работает для showSingleCategory.

Невидимую кнопочку на поле и кликать ее - еще как пройдет, это именно так как все вышеописанное и работает.
Java Script только получает идентификатор документа - например поле в котором хранится его UNID и кликает скрытую кнопку. Поэтому например 2 кнопки с java script на форму - одна Изменить, другая Удалить, 2 скрытые кнопки с названиями DeleteSelected и CorectSelected (в этих кнопках получить документ по его UNID и делать с ним все что заблагорассудится уже просто).
В коде java script меняем вот эту строчку
window.document.forms[0].CorrectSelected.click() на соответственно
для Edit - window.document.forms[0].CorrectSelected.click()
для Delete - window.document.forms[0].DeleteSelected.click()
 
L

LuMee

Для: Andre
Такой вопрос: поле с UNID документа прямо так и называется - UNID? Notes на него поругался, мол "fRight.UNID doesn't have properties" (это при попытке применить к нему value). Или здесь нужно заводить некое CFD-поле, в которое будет писаться @Text(@DocumentUniqueID)?
 

Andre

Green Team
29.07.2004
114
1
BIT
2
Да конечно, поля необходимы. Упустил.
В моем примере имеют следующую расшифровку:
на форме основного документа - поле embViewSelDocUNID - у меня editable, но я думаю что это не принципиально
на форме документов отбираемых в embedded view - поле UNID - CWC (computed when composed) с формулой @Text(@DocumentUniqueID). C типом его по идее можно тоже играться.

Именовать поля можно как угодно, как нужно, как привычнее ... , только поправить в коде ссылки на них.
 
L

LuMee

на форме документов отбираемых в embedded view - поле UNID - CWC (computed when composed) с формулой @Text(@DocumentUniqueID). C типом его по идее можно тоже играться.
А зачем CWC? Имхо, CFD (ну для display, не помню точно) логичнее - зачем по десять раз одно и то же (UNID) сохранять? Или есть какие-то вилы?
 

Andre

Green Team
29.07.2004
114
1
BIT
2
Почему CWC - все достаточно просто - у меня все приложения в основном построены на хранении UniversalID в поле в качестве уникального ключа (ну копирование документов в основном запрещено есесно). Передача его опять же в связанные документы и т.д.
Не более чем мое предпочтение. Иногда используется @Unique отдельно или совместно - в принципе для тех же целей - уникальность.
Потому и написал - что с типом можно играться - CFD нравится и подходит больше - значит CFD
 
30.05.2006
1 345
12
BIT
0
А зачем CWC? Имхо, CFD (ну для display, не помню точно) логичнее - зачем по десять раз одно и то же (UNID) сохранять? Или есть какие-то вилы?
А откуда Вы этим полем хотите пользоваться? Из Формы (а CFD-поле существует только пока открыта форма)? Тогда там UNID в любом месте и так доступен (хоть на собаках - @DocumentUniqueID, хоть на скрипте - Doc.UniversalID).
Поле с UNIDом IMHO вообще излишество. Во вьюхе его можно вывести в колонку и без доп.поля. В 6-ке и эта колонка уже излишество. Ну, разве что для формульного агента может пригодиться
 
L

LuMee

А откуда Вы этим полем хотите пользоваться? Из Формы (а CFD-поле существует только пока открыта форма)? Тогда там UNID в любом месте и так доступен (хоть на собаках - @DocumentUniqueID, хоть на скрипте - Doc.UniversalID).
Поле с UNIDом IMHO вообще излишество. Во вьюхе его можно вывести в колонку и без доп.поля. В 6-ке и эта колонка уже излишество. Ну, разве что для формульного агента может пригодиться
Пользоваться этим полем собираюсь из JavaScript'а, решая проблему получения выбранного во встроенной вьюхе документа. А яваскрипт, видимо, доступ к UNID'ам документов не имеет, он может только значения из полей формы дергать - вот и приходится извращаться.
CFD-поле нужно затем, что сохранять его не надо - оно только для этой яваскриптовой нужды.
А вот насчет создания CWC поля с UNID'ом документа по-прежнему неясно - ведь этот UNID можно и без всякой лишней возни получить в любой момент путем NotesDocument.UniqueID.
 

Andre

Green Team
29.07.2004
114
1
BIT
2
CWC поле с хранением UNID - уникальный ключ, используемый для связи различных документов, когда
городить иерархию response не хочется или не представляется возможным (Построение альтернативной респонзной иерархии не в счет, т.е. не только 1 родитель - n детей, но и 1 ребенок - n родителей. Тут другой каленкор немного).

Используя NotesDocument.UniversalID естественно можно получить UNID, но текущего документа. А если нужно получить коллекцию либо документ связанных документов ? вариант NotesDocument.Responses - да, но и getAllDocumentsByKey из view тоже может прокатить, Search тоже никто не отменял.
Отображение связанных документов в embeddedView с showSingleCategory по ключу UNID - в этот же огород.

В общем такое у меня есть архитектурное предпочтение. Хорошее или плохое - вопрос отдельный.
А так - никто не запрещает использовать другой\другие способы, никто не агитирует делай как я. UNID в примере который я приводил с использованием javaScript - не панацея и не догма, способ реализации - тоже. Это просто пример, выдранный из рабочей базы без переделок.

З.Ы. Все это совершеннейшее ИМХО.
 
L

LuMee

CWC поле с хранением UNID - уникальный ключ, используемый для связи различных документов, когда
городить иерархию response не хочется или не представляется возможным (Построение альтернативной респонзной иерархии не в счет, т.е. не только 1 родитель - n детей, но и 1 ребенок - n родителей. Тут другой каленкор немного).
...
Видно, я не так понял. В документе сохраняется UNID другого, связанного документа? Если так, то решение выглядит вполне логично, сам так планирую делать.
Просто сначала подумалось, что в поле храним UNID самого документа, что уже кажется излишеством.
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!