In both theory and practicality, code reuse is an important topic in programming. You can discuss code reuse from two angles.
The first is how the code is reused in a logical way. It is not only through the popularization of object-oriented thought that the familiar way of inheriting. For example, the first built a car base class, and then derived from it, cars, trucks, buses and other sub-class, the function of the base class car is reused by these sub-categories. Another approach is a combination that has been used since the function was invented. For example, we have a wheel, shaft, body, wooden rods and other components, you can assemble a tricycle.
The second angle is how the code in the entity is reused in such a way. From the static library files that need to be connected, libraries that can be loaded dynamically, to script files that are directly referenced, each has its own characteristics.
Code reuse in Lotus Notes can also be analyzed from these two perspectives. Various binary design elements, such as forms, views, are reused in a combination of code, the reusable parts of the form are made into sub-forms, and the only way to save effort when building multiple views is to reuse the columns as components. As with LotusScript and Java code, the two ways of inheriting and combining are optional, as are other programming languages.
LotusScript as Xpages was introduced before the main programming language of notes, is an explanatory script language, but like VB, the original code will be compiled into an intermediate form of code, using lotusscript of other Lotus software, such as Lotus LotusScript, Lotus Word Pro, and others can save and reference compiled files in the form of a. lso file extension. Lotus Notes does not support this approach, but instead saves the compiled code and the original code in the design element that contains the LotusScript. In the proxy, script library, form, etc. containing lotusscript design elements, respectively, you can see the data type of the agent LotusScript the following fields $assistaction_ex, $ScriptLib _o, $ $FormScript _o, $$ Script_o, where the contents are compiled LotusScript called Script object. This explains the pre-run compilation, although it makes the lotusscript run faster, but also brings a side effect to the call between scripts that are located in different design elements. Reusable scripts are typically centrally placed in script libraries, which are referenced by forms, proxies, and so on. The compiled scripts stored in these caller design elements contain information about the various common items in the script library that can be called, such as variables, functions, and classes.
When code changes in the script library are recompiled, the information about those common items that are saved by the design element that invokes it may be inconsistent with the actual script library, which results in a common run-time error type mismatch on external name <name> and cannot find external name <name>. If the variables and functions that are being used are changed, such as being deleted, modifying names, parameters and return types, and so on, the script cannot be executed, regardless of whether it is compiled or not. But in fact, even if none of these changes, these errors often arise. To avoid them, you need to compile the scripts used in the design elements of the script library once you have modified them, either by modifying them slightly and then saving them, or by recompiling all the LotusScript commands with the designer. In general, each common project declaration of the script library changes, the caller must recompile, and if the private item such as a private variable or a private member of a class is modified, or the internal code of the function changes, the caller does not need to recompile.
In terms of the entities being reused, the code that an app wants to reuse other apps must be in the same database, that is, each time it is reused, a copy of the code is created instead of referencing the same code. 50. Replace design and Refresh Design--lotus notes for program deployment and update Theory and 51. Replacing design and refresh Design--lotus notes's program Deployment and update practice discusses many of the issues with the Lotus Notes program inheritance design that are related to this fact. In addition to the problem with the compilation described above, the usual template changes, to update the application that uses it, not only to replace or refresh the design, you may also need to redesign the update, and then recompile all the scripts.
This reuse is actually a suboptimal pattern that is constrained by the Lotus Notes architecture. To this end, Lotus Notes theoretically proposes a solution-a single copy template. When the design of a database inherits from this template, only a reference to the original design element is generated for each design element, and Lotus Notes automatically obtains the design elements in the template based on this reference when a design element is used. If you build a copy or copy of the database, notes replaces the reference with the actual design element, so that the new database does not have a single copy template in the same environment.
This sounds like a good idea, and the actual application requires additional attention due to the nature of Lotus Notes and the constraints of the scene. We know that the Notes client has a good and efficient caching mechanism. When you open an app on a server, the Notes client caches the design elements that were first read, such as forms, views, proxies, and so on, to the Desktop8.ndk file (a slightly different version of the cache file name), or you can view and compress the file using Workbench properties. The next time you use this design element, notes will use the cached version directly, eliminating the reading of the database on the server. Until this database is closed, the session ends and the cache is invalidated. Re-download and cache design elements from the remote database the next time you open the same database. This mechanism is a perfect fit for a single copy template. If multiple databases on the server inherit from a single copy template located on the same server, we modify a form or proxy in this template, and all databases that reference them will automatically use the latest version the next time the user opens.
But there is still a gap between this scenario and the actual environment. As we mentioned before, formal servers typically do not allow developers to directly modify the design of databases on them, so that the Automatic updates described earlier are missing the premise. If it is in the local development environment, the original is feasible and effective. However, the notes client's caching of the design elements of the local database seems to have a different approach, and after the template has been modified, even if it exits and re-enters the database that inherits it, the old design element remains visible unless the notes client is turned back on and the update is only effective. Another method is to manually refresh the design of the database that inherits it once the template has been modified.
Also, after the LotusScript in a single copy template has been modified, it is still likely that the database that inherits this template will need to recompile the script to avoid the errors discussed earlier, and in the process of "recompiling all LotusScript", in order to save the compiled code, Notes will replace the original reference design element of the link to the element entity, which becomes the same as inheriting the Normal template, the changes in the single copy template can no longer be directly reflected in the database that inherits it. To restore the intent of a single copy template, only the design of the database that inherits the design is refreshed again.
So being able to effectively apply a single copy template to a scenario like the Lotus Notes help as an example presents a large number of design-stable mailboxes that inherit a single copy of the mailbox template to save a lot of duplicated design elements taking up space.