Embedded View from a Different Database – A Scalable Alternative

One of my standard interview questions is to pose a challenging real-life scenario I encountered a few years ago. The scenario posed is of a suite a databases developed for use on Notes Clients minimum release of 6.5.x and maximum release of 7.0.2. The requirement is for users to open a document in database A and view and access a small number of related documents in databases B and C. The related documents in databases B and C are restricted with reader access, and the solution needs to respect those security constraints. The additional challenge is that the solution needs to be scalable to work in a development environment, and internal test environment, a UAT environment and the live production environment.

The intention of the question is not to receive a right or wrong answer, but to assess the candidate’s approach towards a complex scenario. After all, as an IBM Business Partner we’re looking for customer-facing developers who can take a customer requirement and identify an efficient and, when necessary, innovative solution to technical challenges. We also develop and support a number of complex systems that require our developers to identify and elicit pertinent information from end users and in some cases retain a large amount of information, constantly filtering for relevance, while investigating a support call. So what I’m looking for is to assess the candidate’s ability to:

• think clearly when faced with a complex problem
• filter customer requirements
• identify what additional relevant information they need to know
• identify and retain the crucial pertinent points while assessing potential options
• show a breadth of technical knowledge both for identifying and discarding options
• quickly assess the feasibility of potential options or next steps required to evaluate their feasibility
• clearly and concisely explain a technical solution

Now, I would also be looking for a candidate to challenge me (or in a real-life situation, the customer) and ask about the possibility of upgrading the environment to Domino 8.x, whereby a composite application or XPages could be used. But the key step in the technical cognitive process I’m looking for is an awareness that from R6 onwards you can use embedded views from a different database, but that you cannot compute the database path dynamically, you effectively hard-code it to a specific database. This is why I wouldn’t advocate using that method – it requires prohibit design refresh to be set on the relevant design elements, which makes migrating future changes a nightmare.

The actual solution I used hinged on the fact that there were a small number of documents that would be retrieved from databases B and C. This allowed me to have Computed Text within pass-thru HTML that created an HTML table. Opening the documents was done using the notes:// protocol. Because there were a small number of documents, it would never cause problems with the amount of data returned.

More recently, I had a similar requirement of showing and opening documents from a different database, still for a maximum release of 7.0.2, but with many more documents being returned. Again I revisited my thinking process and came up with an alternative solution that works nicely and could someone’s sanity! Again I acknowledged with an element of repugnance the possibility of using embedded views pointing to a specific database. I didn’t dismiss it out of hand. I might still have considered it if the only alternative I could think of gave little advantage on scalability but gave an unacceptable user experience or took considerably longer than an embedded view obviously would. However, if I were to use the embedded view, I would definitely ensure the embedded view was in its own subform to minimise the impact.

My cognitive process was that if I wasn’t using an embedded view pointing to a different database, all the design elements needed to be in the target database. That meant opening some kind of interface in the target database from the source database. A dialogbox can only use a form from the current database, so that was discarded. I didn’t want a button that opened a separate form in a new window, I wanted to provide something slicker. This meant opening the source document in a frameset and somehow opening a design element from the target database in the alternative frame, a similar user experience to the frame at the bottom of an email that allows you to see the parent or in the old Discussion and Teamroom databases. So the first step was to create a frameset with two frames, one for the source document which I called “header”, one for my target which I called “footer”. On the lower frame I set a Border Caption on the third tab of the Frame Properties box set it to show both the arrow and caption, and collapsed the frame to ensure it also appeared collapsed when I opened my document. I then went to my form, and on the Launch tab (third tab) of the Form properties I set it to Auto Frame using the frameset I had just created and launching in the “header” frame. In my target database I created a DocViewer form with two hidden editable fields – one Text field for the document reference that was my key and one Authors field for the author – and an embedded view showing a single category of the documents matching my reference. The end users would already have Author access to the database, so access to this new form wasn’t a problem. That just left linking the two. In the PostOpen of the form in the source database I added code to get / create a document using the DocViewer form in the target database and set my key field. Then I just use the following code to launch the document in the footer frame and set focus back to the header frame:

Call DocVwr.Save(True, False)
Call uiw.SetTargetFrame(“footer”)
Call uiw.EditDocument(True, DocVwr)
Call uiw.SetTargetFrame(“header”)

The final database is not yet live (the customer came back with some minor UAT amendments this week after a couple of months of testing, which is what prompted this article – I had forgotten what I’d done!). But it looks like a nice, satisfactory, scalable but technically not particularly complex solution.