Skip to main content
    Country/region select      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

I've previously alluded to the fact that I'm aware that developers would like to be able to specify which database an embedded view comes from via a formula, as opposed to the current scheme which has the replica ID "hardcoded" in.
This is something I would like to do as soon as possible, but as soon as possible in terms of large-product release cycles, doesn't mean next week, and even when it's in the product, not everybody will be upgrading at once.
That being the case, I'm curious what people are doing as an alternative currently. What have you done, what works in different situations, what can you almost do as an alternative if only... and so on. We're going to put the feature in, but I want to know what workarounds are out there.

Andre Guirard | 16 May 2007 03:25:26 PM ET | Caribou Coffee, Minneapolis, MN, USA | Comments (21)


Andy Broyles | 5/16/2007 4:29:28 PM

I have a situation where we use templates with embedded views from other 'related' databases extensively.

That is where the abstracted REVM ( { Link } ) came from. See my blog's write up ( { Link } ) for more detail.

REVM uses a DXL export and import routines to identify the embedded views and then fix the Rep IDs.

Our templates have very similar 'setup' code that do this process on a very specific basis.

2) yeah, it sucks :)
John Head | 5/16/2007 4:40:56 PM

what we have done is to either use dxl to fix it (and that just is horrible) or to build a subform that is really html and some js and xslt to mimic our own embedded view.

Please fix it .. will save us quite a bit of headache!

3) @subset(@DBlookup))
Elijah Lapson | 5/16/2007 5:07:08 PM

Yep low tech all the way here. Its always fun teaching the new developers how to code tables into view column formulas. :)

BTW being able to use subforms across dbs has changed my life.

4) Subforms
Doug Finner | 5/16/2007 5:16:25 PM

I'm just breaking into this kind of design (and man is it saaaweeet -*) and am planning to use subforms. Our apps tend to be grouped by projects with each project getting the same set of dbs. When I have an app that will use embedded views from remote dbs, that db will include one subform for each remote view. Add a program, add a subform. The db will most likely use a profile doc to define the program and that will drive which subform(s) are loaded in the appropriate doc.

On the other hand, if REVM works in R6.5, that might be a better way to go.

(*) Had my eyes opened by Chris at Interface Matters - Oh THAT's what you can do with those things! When you get stuck in an old version (4.6) for a loong time, you kinda loose sight of some of the new stuff.

5) Don’t bother...
Nathan T. Freeman | 5/16/2007 5:46:26 PM

Dude, forget fixing the embedded view target. It's only one of about 15 problems with embedded views.

Make them all go away by giving us EMBEDDED FRAMESETS. Those are fully programmable at runtime, are addressible via @SetTargetFrame, respect form formulas, can be dynamically sized, and can easily point across template models. Oh, and they can be resized by the user at runtime and include captions.

Ever built a webpage that included an IFRAME? Remember how useful it was? Wouldn't it be nice to do that in a Notes client? That's what an embedded frameset is.

In one fell swoop you could support runtime dynamic targetting and any multitude of design objects. Heck, if you built that kind of encapsulation, you could probably embedded composite elements in the middle of a form via a frameset, even if they weren't meant to be included in the middle.

I've asked for this in a couple of other places, and for some reason people don't seem to understand how ridiculously powerful embedded framesets would be. I guess those people never build templates with frames, but that seems weird to me, since every template from IBM is built in a frameset structure.

6) by the way...
Nathan T. Freeman | 5/16/2007 5:48:19 PM

The DXL approach ends up being painful, because it becomes tough to do design inheritance. You end up having to put your embedded view in a subform with nothing else, and prevent inheritance on that subform. Yuck.

Andre, this situation is a CLASSIC example of how core Notes Dev doesn't understand multi-NSF applications.

7) Ugh
Erik Brooks | 5/16/2007 7:15:46 PM

Wow, I've been doing so much development on the web over the past few years that I forgot about this problem in the Notes client.

Obviously it's pretty easy to work around this problem on the web. But just thinking out loud here:

I wonder if Ben's Midas LSX toolkit has a way to tackle this? Maybe there's a way to "massage" the replica ID via the C API that wouldn't be too cumbersome?

Nathan's spot-on with @6 and multi-NSF apps -- we run a mammoth app that (thankfully) runs on the web, so we're URL-hacking our way around this like happy little mice. Now, if we only had @SetDocField() and @GetDocField with an optional 3rd parameter of a database... but, I digress.

Aside from design inhieritance as Nathan mentions in @5, another problem with a DXL-based approach is the lack of full round-trip fidelity. E.g. I just had an SPR reported for lack DXL support for custom date/time and currency formatting in view columns (form fields, too).

8) Too professional
Mika Heinonen | 5/16/2007 8:40:36 PM

When I say this, I can already expect "Notes Believers" jump onto me. But that fact is, when you write professional Domino applications for the Web, the only thing you need is:

1) Views

2) LotusScript agents (and Script Libraries)

3) Databases

Everything else is or will be not enough when your application grows. Yes, forget about Forms and their Fields, Pages, Framesets, Image resources, Web Services and all other "crap".

Even Notes Databases will be "crap", although this takes a long time, and you need a really huge user and transaction base when you reach this point. Then the next logical step is to start using DB2 databases on, or beside your Domino server.

9) Small correction
Mika Heinonen | 5/16/2007 8:54:06 PM

3) Documents

10) I agree with Nathan...
Simon Scullion | 5/17/2007 4:25:50 AM

Embedded framesets would be a huge step forward.

However, correct me if I'm wrong, but is the issue here not the same for any elements that we select from other databases, whether from the Create > Embedded Elements menu, or when building a frameset? Is it not the replica ID of the database that effectively gets hardcoded in all these cases?

For consistency if we're going to get control for embedded views, it's be good to have it across all "embeddable" design elements.

11) A Caveat
Andy Broyles | 5/17/2007 8:50:02 AM

I would like to add a caveat to my original comment...

After thinking about Nathan's comment about locking the subform design, I realized that I suffered from a limited perspective when 'solving' this problem with REVM.

In my world, I have a one template/one application relationship, not the more typical one template/many application relationship that Notes has historically had; and now see from the expanded perspective that REVM falls short in those types of situations.

In my defense, our application has ~25 related databases and in all of our deployments there is only one set of these in an environment and those 25 databases depend on 26 templates (one shared 'common' element template (think of the OpenLog script library deployment) and 25 specific database templates.)

After the initial install process where we build the production databases from the templates (we have a script that does this for us,) we run a REVM-like scripted agent that updates all of the templates' forms and subforms to reflect the appropriate views in the production databases, then design refresh the production databases to pickup the revised subforms.

It is this series of hoops that I would like to see corrected by allowing computed embedded view database targeting.

I also think that embedded framesets in a form would be awesome, but think that you should fix existing functionality (remote embedded views) first before adding new functionality (remote embedded framesets.)

12) A little more...
Nathan T. Freeman | 5/17/2007 2:34:06 PM

@10 - The content of a frame can be determined using @functions at runtime. You literally just build a string to determine the path of the database you want to show, much like @DbLookup. So an embedded frame could point to any NSF that could be determined by an @formula at runtime. Replica IDs don't enter into it.

@11 - Glad you can see where I'm coming from, Andy. And yeah, it only matters when you're trying to "productize" your templates so you can product 50 copies of the same NTF suite on a given server and/or environment. The reason I'm advocating just doing embedded framesets is because I think it solves all the issues with embedded views at once. After all, it's not just remote targeting that matters here. What about...

Form formulas

Dynamic height controls

Addressable content (ever tried to get the selected document collection out of an embedded view from the container form? There's a way, but it is FAR from easy.)

Those are just the BUGS with embedded views that could all go away with embedded framesets. I have no idea what would be easier to accomplish -- fix all those bugs? Or just make them irrelevant with the new feature -- where you just change the documentation on how to build embedded views with advanced capabilities?

My thinking is that from a programming standpoint, it's easier to create the new facility than fix all the existing code of the old one, but maybe I'm wrong.

13) You might be able to do what you want now just with framesets...
Kevin Pettitt | 5/17/2007 4:20:02 PM

I think Nathan in onto something with the idea of embedded framesets. That said, I've been having great success lately in building dashboard-like interfaces (hats off to Chris and Nathan for the inspiration) using standard framesets. Although the "_top" level window is a frameset and not a form, it's still of course possible to place form elements in various frames depending on your needs.

As others have pointed out, a frame's content can be computed in such a way that it can dynamically pull elements from different databases. It's worth noting that you can also control the content *type* programmatically. You might for example have a single frame that variously displays a view, folder, page, other frameset - you get the idea. Depending on how imaginative you want to get in terms of nesting framesets within framesets and doing cross frame targetting, you can probably accomplish most of the things you currently do with embedded views. The bookmark database has a lot of this sort of functionality built in but you'd never know if you only use the Workspace/Chicklet page as your home page.

You will have to be careful when saving and "closing" documents displaying inside a frame to avoid closing the entire database window, but it can be done. I've also had to invent an elegant kludge (oxymoron?) to avoid NotesUIDocument errors when deleting documents from a view that are currently being "previewed" in another frame.

Perhaps it might be worth putting some energy toward improving programmability of various cross-frame event triggering and refreshing? Considering the push toward composite apps this might already be happening.

14) programmatic access to embedded design elements
Slawek Rogulski | 5/21/2007 12:08:27 AM

What takes too much effort now is synchronizing events on embedded views with the container form, for example, the close event. And I would like to be able to programmatically access the embedded view as if it was a field in the document. I should have said as if it was any other design element on the form, but we cannot even do that. I cannot say NotesUIDocument.BottonX.Disable() or NotesUIDocument.FieldX.Disable(). And like Nathan pointed out I have to jump through hoops just to get NotesUIDoc.EmbeddedUiView.SelectedDocs.

Framesets will be an improvement on embedded views in some ways but programmatic access from the container design element to the embedded elements is just as important.

15) You’d get ’em...
Nathan T. Freeman | 5/21/2007 7:04:46 PM

Slawek, with embedded framesets, we'd presumably get to use @SetTargetFrame. At least, that would be a qualification in my mind.

16) only if we get back a handle to the embedded element
Slawek | 5/21/2007 9:31:44 PM


Like so ...

uiWorkSpace.setTargetFrame ("someFrame")

set uiview = uidoc.openUIView ("someView")

And since I am already in the context of the uidoc why cannt I just call the methods with the context being implied?

But why not just say this

set uiview = uidoc.openUIView ("someView", "someFrame")

17) nothing revolutionary
Slawek Rogulski | 5/21/2007 10:25:37 PM

One more thing. None of this is revolutionary, not in the least. Any old desktop UI framework has had that and a lot more for eons (in IT dog years). I know that Notes/Domino has other advantages but they are seriously getting overshadowed by the fact that in other respects it is feature incomplete. So we jump through hoops trying in vain to merely equal to the run of the mill efforts of the VB collective, never mind surpass them. But don't get me started ;-) In any case better late than never I guess and I do appreciate a forum for offering ideas for improvement. I guess my point is that with such techniques we are only playing catch up. Although that's as good a place to start as any.

18) The art of the possible
Nathan T. Freeman | 5/22/2007 8:02:42 AM

@16 - I'm advocating embedded framesets for the simple reason that we're way more likely to get a combination of two things that Notes already does than to get an entirely new programming model for embedded elements. I'm proposing a tweak as a solution to a whole set of problems, instead of a massive amount of limitation fixing.

And yeah, we're WAY behind on this stuff. Even JavaScript has pretty much comprehensive access and programmability of anything that appears on the screen, including full drag & drop implementations. All I want right now is an <IFRAME> tag equivalent.

19) Fair enough
Slawek Rogulski | 5/22/2007 12:00:39 PM

@18 - You are realistic and I am idealistic.

20) embedded views
Mike VandeVelde | 5/25/2007 6:51:43 PM

I like the embedded frameset idea. But I think that would have to be in addition to the already existing embedded views?

The source selection for embedded views should be the same as what is used for source selection in frames. So if you rearrange embedded views to use the existing picker for frame sources, i guess why not throw in embedded framesets while you're at it? ;-) It's the same picker that you get for outline entries too. It's already in there, just hook it up! Standardization right?

Also while you're playing with embedded views, what about fixing the expand/collapse all weirdness with show single category?

Thank you again for the opportunity to contribute.

21) embedded views
Mike VandeVelde | 5/25/2007 6:59:16 PM

Oh and what we do is always release embedded views on their own in a subform. Then we go through all the destination databases, remove the embedded view that points to the template, replace it with the embedded view from the appropriate database, prohibit the subform, and hope it never needs to be changed!

DXL stuff is possible I suppose, but the balance just hasn't tipped that far to make it worthwhile yet. Once we had a system like that in place, I imagine we would use embedded views from other databases more often. Or we could just wait for it to be built in!

@3 subforms accross dbs?? That could be very interesting! But I don't see how to do it? If I put a computed subform, how do I specify the source database? If the subform could be in the source database, and then embedded in the destination database, that could really make things simpler!

 Add a Comment
Comment:  (No HTML - Links will be converted if prefixed http://)
Remember Me?     Cancel

Search this blog 


    About IBM Privacy Contact