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 created a LotusScript agent in a new database. I'd like to hide the code so that the customer cannot see it.

I found this help document that talks about hiding the design of a database, which also hides the LotusScript.

Is this the way to do it? Or is there a better way? Someone said I might have to create a library, but wasn't sure.

The short answer is, design hiding would work for what you're talking about, but it's a little complicated, so you might want to use a simpler alternative.

The simple alternative is to put your code in a .lss file on your hard disk, and use a %include statement in your agent. The design of the agent isn't hidden, but the source is not visible.

The down side to this is that the code isn't stored in an nsf anywhere, so you're basing your design on something stored on a local file system. This makes it possible that the source will be lost, or that you will have multiple developers working on the same agent with different versions of the code, and which one is used depends on who saved the agent last, and you can't tell what version is being run from looking at the agent.

However you manage to hide the source code, another thing you'll have to consider is that customers will be unable to edit the agent. If it's a scheduled agent this is inconvenient, since it means they can't change the schedule.  So, rather than hide the source of the agent, you could hide the source of a script library containing the guts of the agent code, and have a non-hidden agent that "uses" the script library.  The source code of the agent would be visible, but it would just contain a call to the processing function in the library, so you aren't giving anything away.

If you feel it's worth the extra work to use the design hiding feature, here's what you need to do.

To begin with, where the help says: 'Check both "Inherit future design changes" and "Hide formulas and LotusScript."' that is completely wrong. If you hide design you do not want to continue to inherit from the template.

Let's first consider the case where you want to inherit an entire design, instead of just one script library.  It doesn't usually make sense to have one template with its design exposed, and a nsf file with its design hidden. You need a pair -- the nsf file and the template -- with both their designs hidden. This lets you manage the design of multiple applications from the template. Then, you also need a second template where the design is not hidden, so that you can still edit it. When you have a new version of the design in the non-hidden template, you use Design Replace to update the design of the hidden template but DO NOT continue to inherit.

Why not inherit changes? Because the hidden elements are different from the original elements -- in that they're missing the source code. The DESIGN task on the server notices that the design elements are not the same, so it updates all the design elements in the hidden template (or database). Then, because the design elements in the hidden template are supposed to be hidden, it strips the source code from them. But this means they are still not identical to the non-hidden template, so the next night all that work is repeated.

When you have a hidden template and a hidden NSF, this conflict does not occur. Because the design elements in the template don't contain source code, the source doesn't need to be stripped from them after they're copied to the NSF. So the design refresh process works just fine between these databases. This lets you maintain multiple copies of the app with a single template, which is good.

Now, let's suppose you want to hide just one design element. You still need a template with the entire design non-hidden. That's where you do your development work -- let's say its template name is One. You should also have another template with a complete copy of the design which is hidden -- its template name is OneHidden, and you update it via design replace, not checking the "continue to inherit" box for reasons described above.

Next, you need a template containing a mix of hidden and non-hidden elements -- its template name will be OneCust. You produce this template by initially creating the database from template One choosing not to hide design.  For this one, you can continue to inherit from the template. Then you open the new template in Designer, find the design elements you want hidden, and change them to inherit directly from OneHidden. Now, when you refresh the design of the new template, the unhidden elements that you have flagged to inherit from OneHidden will be replaced by the hidden versions of those design elements.  They can no longer be edited and the source code isn't in them.

Of course, can also make an NSF directly as described above for OneCust template, but it's nice to be able to pop off multiple copies of the application without having to do that work over, so it's useful to have a template.

An extra step for additional credit: One problem with delivering the template OneCust to customers, is that it contains references to the templates One and OneHidden, which the customer doesn't have copies of. This results in annoying server log messages from the DESIGN task complaining that these templates were not found. Therefore, you might want to have a fourth template containing the published design, which you would call OnePub. You create this from OneCust and choose to not hide design and not inherit changes -- and you put a release number on it.

So, to edit the design and make a new release, the procedure is that you create a test database from the One template with nothing hidden.  You make your edits in the One template and refresh the design of your test database.  Once it's right, you replace design of OneHidden -- yes to hide, no to inherit. And you refresh design of OneCust.  And then you use OneCust to create a new OnePub (v1.1).

This part doesn't apply to you at present, but you also need to watch out if you use a hidden shared actions note, as described here:

Andre Guirard | 12 November 2009 05:42:52 PM ET | Man-Cave, Plymouth, MN, USA | Comments (6)


1) Delete $Scriptlib w/ DbDesign
Leonel Tayler | 11/12/2009 3:51:41 PM

I also use a modified DBDesign library and delete the $ScriptLib field from specific design elements for some years now, and never got a problem. Is there a known issue about this? It seems more efficient and faster to me.

2) .LSS great for well-debugged libraries
Jake White | 11/13/2009 9:09:41 AM

I really like having "core" LotusScript libraries stored in .LSS files.

In addition to "hiding" any proprietary code (while still enabling the customer to modify routines that USE the code), there are other advantages.

- I use a text editor with syntax checking and a "project" capability which allows search/replace through multiple files. Very useful.

- When you use the "library", it really is exactly the same one in every database -- they all come from the same file, not some cut/paste one-time snapshot.

- You don't have to step through code that contains well-tested "core" library functionality. So, for instance, I can say

set view = appSession.View("DBCODE","ViewName") and not have to step through the code that looks up the db referred to by "DBCODE" and finds the appropriate view. Nice.

The disadvantages?

- You can't step through code when you want to. Although you can easily cut/paste the whole LSS back into the script library temporarily.

- You have to use some kind of source control system and fixed folder locations for a team to use the files. This is actually an advantage, as Subversion (our source control system of choice) allows per-revision tracking (and diff) of script changes.

- You have to treat shared library APIs as published and immutable. You have to maintain backwards compatibility. This requires some judgment and experience, although there are good programming books on API design.

How this all works for me might change with Eclipse/8.5.1. We'll see -- I'm experimenting with best practices already.

3) Just dump the source code
Pierre Lalonde | 11/13/2009 10:13:07 AM

Haven't read everything on your post, but we do it by deleting $Scriptlib FIELD.

4) Should have read Leonel comment first...
Pierre Lalonde | 11/13/2009 4:02:10 PM

As for Leonel, haven't got any problem with this method.

5) Modifying the master template name
Ronald | 11/15/2009 9:21:29 AM


We are trying this method to have certain design elements hidden.But after the design is hidden the master template name cannot be modified.

And if we set the master template name before we make the design hidden, it is removed after the design replace.

Is there a method to set the master template name of a database with a hidden design?

We are using 8.5.1.

6) Hide and unhide with a tool
Rob Goudvis | 11/18/2009 9:18:31 AM

I have written a tool that allows you to remove the source code from any selected Lotusscript and replace it by a LSS call. You specify a target library so all extracted source code will go to the same location.

And my tool has a function to reverse the above.

The result is that you still can use the Designer to do your development, because it is very easy to remove and restore the source code.

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

Search this blog 


    About IBM Privacy Contact