Have you ever had Notes application A that had related data in Notes application B where you wanted to show the application B data when you opened a document in application A? I have, and I found there are lots of ways to combine data like this. If it were all in one database, it would be pretty trivial to create an embedded view and show the single category that relates to the open document. It gets complicated when you want to leave the data in its source database rather than copying it to where you want it, and feels almost impossible if you then introduce multiple environments (eg. development, QA and production).
Composite Applications, introduced in Notes 8, were one way to accomplish this, but they never really caught on, due in part to their own deployment issues. XPages is the latest silver bullet that can be used to slay this beast. But what if you don’t have Notes 8.5.1 and aren’t going to move to it in the near future? Or you don’t have the time to focus on learning XPages right now?
There is a way to make these related applications work in a configurable way in the Notes 6 and 7 client. This is not original thinking. See Nathan Freeman’s blog (ntf.gbs.com) for the Sesame Street and Area 51 demos for the earlier documentation. I just thought it was worth bringing up again.
The entire solution is based on three features of Domino Designer and Notes that haven’t gotten a lot of attention: computable frameset contents, embedded editors and forms that open in framesets. Nathan’s Sesame Street demo showed how you could embed a fully functional frameset on a form. That was great, unless you only wanted a single category of a view. That problem was solved in the Area 51 demo.
For this demo, I have an application catalog. Not *the* application catalog that each Domino server has, but one that adds on to that catalog to add a description, an application owner and technical support staff. Rather than copying everything from the system catalog, we’ll reference the catalog from within our application. I’ll refer to the application catalog as the “source” database and the system catalog as the “target” database. The source database documents will contain the replica ID of the application database that will be our lookup key for the target database.
Target Database 1. Create a form in the system catalog with an embedded view on it, with the view being one categorized by replica ID. You can create a view specific to your needs or use one that is already in the system catalog.
2. Set the form so that it does not appear on the Create menu.
3. On the embedded view, the Show Single Category property should be set to @Word(@Environment(“Catalog_Ref”);”~” ;4). The environment variable will be set by the source application and will be explained in the next section.
4. Save the form with the name OneReplica.
This must be created in the target database so that you can choose the “Current Database” option as the source of the embedded view. Because there is not a way to programmatically select the source of an embedded view, this ensures the proper view will always open, whether you are looking at your Dev, QA or Production system catalog.
Source Database This database should already have a form in it for the application items that you want in addition to what is in the system catalog. To make this work, you need a field on the form for the replica ID of the application, and the value should be in the formula format (12345678:87654321), unless you created a new view in the target database that reformats the replica ID. You should also have a view that lists the application documents.
There are two elements that need to be added in the source database and one change to the application form you already have. The new elements are a frameset that will display the form from the target database, and a wrapper form that is set to display in a frame of the new frameset. On the application form, you need to add an embedded editor that will display the wrapper form.
1. Create a frameset with three frames: two side-by-side on top and one full width on the bottom. Set the top frames to a relative height of 1 and 50% width. The borders should be set to not be 3D and 2 pixels in width.
2. Name the top left frame NotesView and set its target to NotesDocView. Set the Content Type to Named Element and click the ‘@’ icon to enter formulas to determine the element. The kind of element should have the formula @Word(@Environment(“Catalog_Ref”);”~” ;2), the database should be the formula @Word(@Environment(“Catalog_Ref”);”~” ;1) and the element name should be the formula @Word(@Environment(“Catalog_Ref”);”~” ;3). The kind and name of the element could actually be constants, but it is a better practice to compute them in case they need to change later or you want to use this frameset for more than one purpose.
3. Name the top right frame NotesDocView.
4. Name the bottom frame InvisibleMan. The height of InvisibleMan should be 0 pixels, Scrolling should be Off and Allow Resizing should be No. We don’t want to see this frame; it is used only as the target for the form we want to open in a frameset.
5. Save the frameset as CatalogView.
6. Create a form. It should be set so that it does not appear on the Create menu. On the Launch properties, set it to open in the CatalogView frameset in the InvisibleMan frame. The only purpose of this form is to open in a frameset so the frameset can appear to be embedded on another form. This form could also set the environment variable, but we are not doing so in this example.
7. Save the form with the name Wrapper.
8. In the application documentation form (assumed to have been created previously), add an embedded editor that opens the Wrapper form. In the PostOpen of this form, you need code to set the Catalog_Ref environment variable. The variable should be in the format server!!filepath~Form~OneReplica~replicaID. The server could be computed based on the location of the source application and the filepath is probably constant across the environments, so you could probably enter it directly (remember to escape any ‘’ in the path). The element type and name will be constant and the replica ID is the name of the field containing the replica ID. More likely, the server and filepath for the catalog would be read from a configuration document. Just keep in mind that the location of the target database (that is, both the server and file path) should not be hard coded, because that defeats the purpose of this solution: to make it possible to migrate from your dev to production environment without making programming changes as the moves are completed.
9. Save the updated form.
Once everything is saved, go to your source database and open or create a document using the application documentation form. If all goes well, you should see an embedded view that contains the documents from the system catalog for the replica ID of the database you are looking at, and a box to the right that should display the document you click in the view. See, a real embedded frameset!
If you want to prove that it is configurable via the environment variable, set the environment variable to @Implode(@MailDbName;"!!")+"~Folder~($Inbox)" and see that it opens your mail box.
Once you wrap your head around how this works, the possibilities become nearly endless. Multi-database applications can become far more informative.
XPages: Returning to the Prior Page
Fri, Mar 15th 2013 2:22p Don McNally I read this post from Brad Balassaitis and shared that "I should have blogged that last year when I did it". A couple of people encouraged me to blog it just for a different perspective, so here we go. I have a button in my left navigator that opens an XPage for processing documents with a bar code scanner. That XPage does not include the navigator; it's like a new document. Once the user is done processing, they click a Finished button and I wanted them to go back where they came from. My [read] Keywords: lotus
XPages: Detecting and Logging Field Value Changes
Sat, Feb 2nd 2013 7:22p Don McNally Recently I had a request to add functionality to an XPages application I wrote and implemented last year. They wanted the ability to log changes made in specific fields. I did some searching and found the resources I needed: valueChangeListener code as a managed bean by Tony McGuckin, which was linked from valueChangeListener implementation code from Declan Sciolla-Lynch, which pointed to A better way to update log fields by Chris Toohey I used my "R&D skills" to set up the code in my [read] Keywords: lotus
More Excel Code: Inserting and Copying Rows
Tue, Jan 24th 2012 2:02p Don McNally I was working on some code to export data to a pre-formatted Excel file and, as part of that, needed to be able to insert rows into a range so that the data I added would be included in formulas below it (they were column totals and data summaries). As I find typical when trying to control Excel from LotusScript, I couldn't locate examples of the code I needed. That doesn't mean they aren't out there, just that I couldn't find them. After some experimentation and some dumb luck stumbling on [read] Keywords: lotus
Inheriting Field Values for Names Fields
Tue, Jun 28th 2011 11:05a Don McNally I had a problem last week with a couple of forms that have fields that inherit values from fields on the document that is open when the new document is created. On one form, the field values were set properly, but on the other they were not. The form being created is a response-to-response form. The form that worked was a response form, so at first I thought the problem with the form that was not working was because it was a main form. I discovered that wasn't the problem when I was able to get [read] Keywords: lotus
Barcodes in Lotus Notes Applications
Thu, Mar 31st 2011 2:02p Don McNally If you have ever wanted to implement barcoding in a Notes application, it may be easier to do so than you think. You really need four things to make it work: A barcode font that is deployed to machines that will be printing the things (eg. paper or labels) that have the barcode on them. LotusScript code to generate the field value for the barcode. Simple barcodes, like Code 39, just need start and stop characters before and after the number you are putting on a barcode, but they have a limite [read] Keywords: lotus