On Karl-Henry’s frustrations… 31 Mar, 2011
In a weird synchronicity, Karl-Henry Martinsson has just posted about some frustrations he’s been having with Domino Designer (I haven’t added the “Eclipse” bit to the end of “Domino Designer” because (a) I know Maureen doesn’t like it :-), and (b) because this issue affects Designer 7 too). So how does one get to this sad state of affairs?
The dutiful developer performs a “compile all” in their database, and is shocked to see a whole load of Lotusscript Error - Syntax Error reports in the compiler window. Whilst the compiler is probably pointing to a load of forms in one’s app (yeah, that’s helpful), the issue is actually with the shared action design element. You know, that bastard anomaly of a design note in Designer, whereby things that look like multiple design elements (shared action buttons)… aren’t (I hates it so I does, hates the shared actions element. Can you tell?)
I encountered this very issue earlier this week in a Notes client application I was performing some maintenance on, and it took me a while to track down. The offending action scripts were referencing some files that must have been stored on the previous developer’s machine, and Designer was not happy at all. As I found to my cost, Option Declare will not fix this issue. Nor will editing and re-saving the offending elements. One has no choice but to go through the code, find the errors and resolve them. The compiler gives little, if any, assistance at this stage.
My solution—which to my mind makes for far better coding practice anyway—is to rip out all the Lotusscript from such shared actions, and stick these routines in a separate library. You then reference these routines from the shared action buttons, and we never talk of this again. Moving the code solves a few things in one fell swoop:
- Shared actions are all stored in one note in the NSF. If this note corrupts (and they do), you lose all that code
- Storing all significant Lotusscript in one part of the application design (i.e. in script libraries) makes far more sense from a maintenance point of view
- When editing Lotusscript in a script library, the compiler behaves itself and tells you about any problems. In shared actions, you’ll be lucky
So what do you know. 2011, and I’m still doing the odd Lotusscript tip… ;-)
Option Declare
Use xxx
Sub Initialise
Call agXXX
End Sub
Life is so much simpler if you just code in Libraries... like Design Synopsis actually has a chance of succeding to find references, when it doesn't go bust because the references are scattered through tons of forms, subforms, views, actions etc etc...Lars Berntrop-Bos#
The nasty problem is, for some idiotic, reason Domino actually puts a copy of the action code from the shared action in the view / form or where ever you use it. So, even though you think you're centralising your code, you're inadvertently laying little time bombs.
Why are the time bombs ? Well, lets say you delete the shared action at a later date. Now, even though you have deleted it centrally, the action does not disappear from the form/view where you used it. It in fact remains fully functional and in the parent design element where you use it. Now you have to goto each element and delete it manually. On a DB with a 50 views and 20 forms....Great! Just farkin great!
Here is the kicker, if you don't delete them manually after removing the shared action, the copy that it does use locally in the design element (form/view), is in fact the original version of the shared action when first installed. So you could even introduce regression bugs into actions that you haven't successfully removed.. Now, that's double jeopardy, beat that one Watson.....
Giulio#