IdeaJam(tm) : Add a optional parameter REFItemName for work with hierarchies of responses

Domino Designer / : Add a optional parameter REFItemName for work with hierarchies of responses

Mon, 23 Nov 2009 14:45:40 +0000

Author: Vlad Sh
Tags: LotusScript @function
Idea:

REFItemName = "$REF" by default or omit this parameter.

apply to following methods:
Call notesDocument.MakeResponse(document As NotesDocument, [ REFItemName As String ])
Set notesDocumentCollection = notesDocument.Responses( [ REFItemName As String ] )
@Command([ComposeWithReference]; server : database ; form ; flags ; [ REFItemName ])
@Responses([ REFItemName ])

probably need to take into account:
notesDocument.ParentDocumentUNID
IsResponse

EDITED: MakeResponse or ComposeWithReference can be excluded from this list, but then give a chance to create item type of "Response Reference List", because now it correctly you can create only MakeResponse method.

re: Add a optional parameter REFItemName for work with hierarchies of responses

Mon, 23 Nov 2009 14:53:46 +0000

Author: Peter Presnell
Comment: Hi Vlad. I'm struggling to understand why we would want to change the name of the reserved field always used to denote the parent document. I would suspect there is a whole lot of Notes code that depends on this field being what it is and at the very least there would be a perfromance hit if Notes had to search through all the fields in a document to find if such a field exists (and what would it do if there was more than 1?).

re: Add a optional parameter REFItemName for work with hierarchies of responses

Mon, 23 Nov 2009 16:02:14 +0000

Author: Vlad Sh
Comment: Hi, Peter.

We can do custom hierarchy, that is to build the hierarchy of types of responses to a different field that has a special type of "Response Reference List" with a value in the form of 32-byte number.

In the view of simply redefined item, which by default ($REF), for example, before SELECT in the view selecting formula write:
DEFAULT $REF := $RefCustom
This enables the formation of different hierarchies, for various dependencies.

So, to create such a field (type of "Response Reference List") necessary to copy now $REF somewhere, then do makeResponse another "parent", rename, resulting in $REF to $RefCustom (or another name) and then return the old $REF in place ...
And in order to get all the "child's" to the "parent" of $RefCustom, must either create an additional view to the selection by UNID or use notesDatabase.Search, that differently, but still affects the performance is not improved.
I proposed setting and functionality techniques could elegantly solve these problems.

I apologize for my English.