Bruno Grange
Bruno Grange
"Imagination is more important than knowledge." (Einstein)
Content
Social
| Dynamic Class Generation and Script Library Load in LotusScript |
 |
 |
| Written by Bruno Grange |
| Wednesday, 03 September 2008 02:11 |
|
Have you ever wanted to create an object in LotusScript, but didn't know at design time what class the object will belong to? This tip shows you how to handle this classic chicken-and-egg issue. Have you ever wanted to create an object in LotusScript, but didn't know at design time what class the object will belong to? It's a classic chicken-egg issue, but I'll leave poultry out of it altogether and base my example on fruit. Take the following (admittedly contrived) example, which creates a fruit instance based on a user specified type: 'Get fruit type. fruitType = InputBox("Please enter a type of fruit:") 'Set type of someFruit based on user choice. set someFruit = new fruitType The main problem with this code is of course the last line -- you can't instantiate a variable at run time unless you know the name of the class at design time. This limitation can become an issue in a variety of scenarios -- for example you may have to specify a class type based on an algorithm, or a profile document, or perhaps you're just looking to write cleaner, more extensible code. One way to solve this problem is to include the class logic in a conditional block. Take the following code snippet: 'Get fruit type. fruitType = InputBox("Please enter the name of a fruit:") 'Set type of someFruit based on user choice. Select Case fruitType Case "Banana" set someFruit = new Banana Case "Apple" set someFruit = new Apple Case "Watermelon" set someFruit = new Watermelon Case Else set someFruit = Nothing End Select There are several issues with this approach. Firstly, you have to change the code every time you add a new class or modify a class name, which makes the module less portable. Secondly, this approach can be time-consuming for code that handles large numbers of classes, and of course as the number of classes increases the code will become less readable. These issues usually result in higher maintenance costs. A third and potentially more serious issue is that you have to load each of the class script libraries into memory, even if you aren't using them, with something similar to: Use Banana Use Apple Use Watermelon Depending on how many classes you have, this issue can have serious effects on performance, particularly if you're loading script libraries from other script libraries, and some of them use global variables or have initialize events. Not to mention that it can be difficult to troubleshoot a program that loads 20 script libraries, which in turn load another 5 script libraries each, which in turn... the execution flow can quickly become unmanageable. Related Articles: |
