IBM®
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: http://www-10.lotus.com/ldd/bpmpblog.nsf/dx/shared-actions-and-hidden-designs?opendocument&comments

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

Search this blog 

Disclaimer 

    About IBM Privacy Contact