|
: -14 : 0 : 14 |
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. |
1) Peter Presnell28487 (23 Nov 2009)
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?).
2) Vlad Sh10679 (23 Nov 2009)
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.
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.
Welcome to IdeaJam
You can run IdeaJam™ in your company. It's easy to install, setup and customize. Your employees, partners and customers will immediately see results.
Use IdeaJam to:
- Collect ideas from employees
- Solicit feedback and suggestions from employees and customers
- Run innovation contests and competitions
- Validate concepts
- Use the power of "crowd-sourcing" to rank ideas and allow the best ideas to rise to the top
IdeaJam™ works with:
- IBM Connections
- IBM Lotus Quickr
- Blogs and Wikis
- Websphere Portal
- Microsoft Sharepoint
- and other applications.
IdeaJam has an extensive set of widgets and API's that allow you to extend and integrate IdeaJam™ with other applications.
Learn more about IdeaJam >>
IdeaJam developed by
