Solved

View based on @dbcolumn Multiple value list in form

Posted on 2004-08-07
10
813 Views
Last Modified: 2013-12-18
I know that embedded views can not be generated by dynamic selection criteria and that the "single category" option (which I use for other things) will not populate, of course, based on more than one value in the form.  But I am using @dbcolumn lookups to populate a multiple value list.  The list is of documents the user chooses as "related" to the current document.  For example, an interview form with a multiple value @dbcolumn lookup field that allows the user to select related People documents corresponding to the people in the interview...(people are a collection documents in a lookup view selected by "People" form).  

I should like to be able to have a view or other method on form that allows me to click and open the "related documents" based on the values (between 0 and n) listed in the "related documents" field.  In the above example, after the user selects the People in the Interview, the embedded view displays all documents containing any of the selected People values in the appropriate field:  e.g.,   "NameField contains any values in list."

Knowing that embedded views don't do the trick, am trying to think of another way to approach the goal:  allow user to select multiple documents, view that list, and click on any item in that list to go to the document referred by the item in the list.
0
Comment
Question by:jwolpert
  • 3
  • 3
  • 2
  • +1
10 Comments
 
LVL 46

Expert Comment

by:Sjef Bosman
Comment Utility
I was proven wrong about the first assertion (embedded views CAN be more or less dynamic, but I forgot how...) and the second I think isn't true as well (but please explain how you intend your view to be populated).

And for the rest, your description is a little vague to me, like do you use @DbColumn or @DbLookup? It seems to me that you're more thinking out loud :)

And maybe here's your answer: is @PickList the thing you're looking for?
0
 

Author Comment

by:jwolpert
Comment Utility
Using @dbcolum, though the lookup method to populate the list field isn't the crucial thing here.  

Imagine a form called Interview and another form called Interviewee(my application is more complicated, involving several kinds of related documents created with different forms, but this will do for simplicity).  
An Interview can involve more than one Interviewee.  As the user fills out an Interview form, he selects one or more Interviewees in the "Interviewees" field on the Interview form.  This field does a lookup from "lookupInterviewees" view as one would normally do.  No worries here.  

But now, ideally, I would have an embedded view in the Interview form listing all the Interviewees selected, so that the user could see more information about the interviewees and click on them to go directly to the Interviewee document for any of them.

I have toyed with copying over the UNID of the current Interview document into the selected Interviewee documents and creating an embedded view with that field as the single category.  This would produce the desired effect, but aside from being reasonably sophisticated querysave code, it creates a lot of potential data consistency problems as the use adds, deletes and modifies the Interviewees.
0
 
LVL 46

Expert Comment

by:Sjef Bosman
Comment Utility
Tel me try to translate your ideas so you can see if I get your drift. So correct me if I'm wrong.

You have a form (Interview) on which (next to the Interview-document) you want to display some information stored in other documents (Interviewee). There can be no parent-response hierarchy since an Interviewee can participate in multiple Interviews (probably?). That's where your embedded-view idea comes in: you want to show a list of documents that have a common denominator: they participated in the same Interview. You tried sharing the Interview's UNID with the Interviewees, but there might be problems regarding data consistency. What would be your problems with that? If deleting an Interviewee is a problem, because you lose historical data (the interview did take place), there's but one way: you have to copy the data you need to the Interview-document. Then, the best way to show the data (IMHO) is a one-line table with in each column a multi-value field that uses a Newline as separator. Of course, if there is too much data and lines would overflow, this method doesn't produce what you want: lines with interviewee-information. As an alternative, but it only works with R6, you can have one single computed rich-text field in which you add a table and put the text in the table columns yourself.

Did I understand what your thoughts are?
0
 

Author Comment

by:jwolpert
Comment Utility
Yeah, I was thinking about using a richtext field and populating it with with references generated by the @dbcolumn People lookup field, but can't figure out how to make these hot links back to the original People documents, which is the point of the thing.

Here's how this works....  I have an Interview document which must refer (as you point out) to many People...and likewise you are correct that a Person can be linked to many Interviews.  I want the user not only to have a list of the People but be able to view that list and click on each one to be taken to that person's actual PersonDocument.  An embedded view would normally do the trick, but only if the linking information is stored in the person document, not the Interview document...which is where the linking information in the @dbcolumn list is.  

Sure, I could write code that cycles through the People list in the Interview document and add the interview's docUNID to a similar list of Interviews in the People document of the selected people...thus generating the structure needed to populate the embedded view (because the embedded view can use a categorized column of "Interviews" and the "select single category" can be set to the current interview's UNID)...no problem there.  But if I use that method, I have to write a lot of other control code in the event, say, that the original Interview document is deleted, or the use decides a particular person should no longer be associated with that interview...in that case, need to get those deleted interview references out of the People documents....this is a requirement of the application, in fact.

Mainly, though, the issue is that I want the user to be able to navigate quickly from within the Interview form to any person document listed in the interview form.

Make sense?
0
Better Security Awareness With Threat Intelligence

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

 
LVL 46

Expert Comment

by:Sjef Bosman
Comment Utility
Sure makes sense. There are two ways I can come up with. You'd have to store the UNID's of the Interviewees in the Interview document.

1. Use the rich-text method, and use the AppendDocLink method of NotesRichTextItem to create your links. If an Interviewee isn't there any more, just skip the document. You might run into some problems with R5.

2. Display a condensed list of information using a DialogBox, and let the user select one of the lines. This is more or less equivalent to using the PickListCollection method of NotesUIWorkspace.

I'm not so very much in favour of using the UNID for permanent linking purposes, because in a copied database all UNIDs will be different so the links won't work. If you're ever in need of removing your database completely and want to use a copy, it won't work. Make sure you have at least a replica running somewhere. But if you store the Interviewee's UNID in a separate field for referencing, you'll be safe.
0
 
LVL 31

Expert Comment

by:qwaletee
Comment Utility
I would consider an embedded folder.  You can easily move the interviewee docs into the folder.  The problem is, you don't want a separate folder per document.  You could have a separate folder per user, if you don't expect to have huge numbers of users and don't expect to have more than one interview doc open at the same time per user.

Another way: I would go with a fixed maximum number of interviewees, and set up docLinks using computed for display fields (so you don't have a rich text update issue)

Finally, you could simulate a view by using a list field with some key values from the target docs, obtained via lookup/search.  User clicks on one, and your code opens the corresponding doc.  You can even use preview, by dynamically changing parent docs.
0
 

Author Comment

by:jwolpert
Comment Utility
That's brilliant.  I'm so glad I joined this network.  I'm not a neophyte Lotus guy (my team built the first domino-based website - www.ibm.com/alphaworks), but I'm rusty and there is a lot of stuff you forget or have never tried.

I'm thinking that generating appenddoclink in a richtext field by looping through the items isn't the worst way to go.  I understand the reasons, but it is still too bad one can't simply build a view based "contains" contents of a field in the form.  sigh.  

Your last point about a list field where one clicks one of the items and is taken to the corresponding doc.  You you say more about the preview idea?  Trying now to figure out the right code to get to a document selected in the list.

Thanks.
0
 
LVL 63

Expert Comment

by:Zvonko
Comment Utility
No comment has been added to this question in more than 21 days, so it is now classified as abandoned.

I will leave the following recommendation for this question in the Cleanup topic area:
    Accept: qwaletee {http:#11754358}

Any objections should be posted here in the next 4 days. After that time, the question will be closed.

Zvonko
EE Cleanup Volunteer
0
 
LVL 31

Accepted Solution

by:
qwaletee earned 250 total points
Comment Utility
And, just for completeness...

> Your last point about a list field where one clicks one of the items and is taken to the corresponding
> doc.  You you say more about the preview idea?  Trying now to figure out the right code to get to a
> document selected in the list.

you know how parent preview works, right?  And you know you can change parents using LotusScript, right?  Well, if you close parent preview, change parents, and reopen parent preview, it will show the parent, all on the fly!
0

Featured Post

Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

Join & Write a Comment

For users on the Lotus Notes 8 Standard client, this article provides information on checking the Java Heap size and adjusting it to half of your system RAM in attempt to get the Lotus Notes 8.x Standard client to run faster.  I've had to exercise t…
For beginners of Lotus Notes user this is important to know about the types of files and their location supported by IBM Notes. Mostly users are unaware about how many file types are created and what their usages are. This Article is fully dedicated…
Excel styles will make formatting consistent and let you apply and change formatting faster. In this tutorial, you'll learn how to use Excel's built-in styles, how to modify styles, and how to create your own. You'll also learn how to use your custo…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

771 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now