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

Something I happened on recently in the course of helping the template developers, that I thought might not be generally known.

When you create a shared action in LotusScript, if it uses unknown names, you are allowed to save that shared action, even though the syntax would be considered incorrect for code used in any other context. For instance, if you write this line in an agent:

Set ctx = GetExecutionContext( doc )

the compiler will complain if the GetExecutionContext function isn't defined elsewhere in the code. A shared action will tolerate this, however, with the expectation that the reference will be resolved at runtime as a function in the form, view, or whatever that includes the shared action.

What's important to realize about this, is that the compiler still can't produce object code with this unresolved reference. So for this shared action, Designer saves only the source code. When the action is used, the source must be compiled at runtime in the context of the design element containing it.

Of course, this is only possible in cases where the source code is available at runtime. So, shared actions containing unresolved references are not compatible with being able to hide the design of your application.

If this is a problem, define a script library that includes the globals and/or functions that you want your shared action and form (or whatever) to share.  Both the form and the shared action would "use" that library. When code is loaded, script libraries referenced in multiple places in the code are only loaded once, and their global variables only allocated once. So if a form event assigns a global that's defined in the script library, and a shared action reads that same global, it will see the value assigned by the form code. Since this can be successfully compiled, the object code is stored, and no runtime compilation is needed.

Andre Guirard | 16 June 2009 01:36:07 PM ET | Home, Plymouth, MN, USA | Comments (6)


 Comments

1) Thanks! That explains some errors we had in the past
Karsten Lehmann | 6/16/2009 2:58:02 PM

But to be honest: I do not like this behaviour at all. Some months ago, I wrote some code in a shared action, because I did not have Designer access to the DB at that time. There was an error in the code, but the shared action could be saved without problems.

However, when I clicked the action, it produced errors now and then (e.g. because a variable had not been defined).

That was EXTREMELY annoying, because searching for the reason wastes a lot of time and it is not obvious to the developer why it happens that way.

In my opinion, there should be an option in the shared action to activate this "don't care" behaviour. By default, this should be switched *OFF*.

Regarding the hidden design issue: There is an alternative way to hide the DB design, which is not really safe for experts (with some hex editor or C knowledge, the protection can be removed), but may be enough for most of the users, who just don't want everyone to mess with the design of a database.

You can use a Sandbox tool called "DBProperty Setter" for this purpose.

Here is the URL:

{ Link }

2) Hiding design not really
Andre Guirard | 6/16/2009 3:58:46 PM

@Karsten, I don't understand how you were able to write shared actions in a database to which you had no Designer access, but whatever.

The way you describe of hiding a design, is also not proof against anyone who has Designer client since they can debug LotusScript code and see the code that way.

One good way to check the shared action code for errors, is to write it first as an agent. Personally, I think you can just leave it as an agent. Shared actions are a waste of space and a performance drag, since the code gets duplicated in design elements and must be loaded whether or not it's used. I prefer to leave the code in an agent and just launch the agent from the action with @Command.

3) Ah, I remember what it was
Karsten HW Lehmann | 6/16/2009 4:24:56 PM

The "Create LotusScript/Java Agents" flag was missing in the ACL. That's why I could create a shared action, but no agent.

We also had problems with hotspot code that did not work properly in hidden design. Is this also a known problem?

4) Shared actions and hidden designs
Andre Guirard | 6/16/2009 4:52:46 PM

> We also had problems with hotspot code that did not work properly in hidden design. Is this also a known problem?

Not to me, but maybe someone else here has run into it. Anytime you have "problems with X in hidden design" you have to start by thinking about whether there could be some runtime compilation going on.

5) Hidden design?
Mael Rivera | 6/17/2009 1:29:40 PM

Who hides design anyways?

I mean, half of your development code comes from somewhere else, why not give the other half back?

I've been developing ND apps for 10 years and only once I've met hidden design. Only caused troubles. Especially for the responsibles of the hidden design code which, of course, eventually they had to unhide.

6) "global variables only allocated once"
Notes Newbie | 3/3/2010 7:21:44 AM

In my Notes Client 6.5.4 I have created a Database with one Script Library and two Forms. Both Forms use the library.

- Form1.PostOpen instantiates the library's LotusScript class A.

- Class A instantiates the library's LotusScript class B.

- Class B calls NotesUIWorkspace.DialogBox to show Form2.

I want to share data between the class instances and Form2 bidirectionally (to check validity of entered data). I've tried (defined in the Library):

- simple public variables

- a public instance of a "messenger" class C

- a public property hiding a global private instance of the "messenger" class C

- a static property doing the same

- a static property hiding a local static instance of the "messenger" class C inside the property.

Neither of them worked. It appears that each Form opens a separate instance of the Script Library, having global variables on its own.

The sub "Initialize" of the library is called twice. The global and static variables have their default values when Form2 accesses them. Correspondingly, the property mechanism to instantiate the classes is executed twice.

What am I doing wrong?

7) Shared actions and hidden designs
Andre Guirard | 3/9/2010 8:12:14 AM

@Newbie, I don't know any way to do what you're trying to do.

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

Search this blog 

Disclaimer 

    About IBM Privacy Contact