automatic recompilation - a great idea in theory but not in practice
Category lotusscript
As has been mentioned at great length elsewhere, Notes/Domino 8.5.1 is a brilliant release. Everything's noticeably faster and less buggy, and some very useful features were added. One of those features, however, caused me considerable grief yesterday, when I had occasion to revisit my dear old friend, LotusScript. Specifically, I was updating the code of a button on a form that referenced a script library - a very familiar scenario for most of us.
What was unfamiliar, however, was that Designer was generating a save conflict on alternating save operations. A save conflict, you say? In a design element? Indeed... in a local template, no less. A local template that doesn't even have a server replica yet. In other words, it couldn't be a replication conflict... it was definitely a save conflict. I was baffled... until I noticed some unusual chatter in the status bar indicating that the form had been updated by an auto-compilation process.
In 8.5.1, a new preference has been added: "Enable automatic recompilation of all dependencies". Sounds good, right? If I make a change to some script library, I want any design element referencing that script library to be using the new code. Except... it nearly always has. I haven't had to manually recompile my forms, for example, in order for them to be aware that I updated a script library they reference. This is Domino, after all... it just works. True, on very rare occasions (usually while working in a complex application that has a ridiculous amount of script libraries), I've had to resort to invoking the "Recompile All LotusScript" option in the Tools menu... but I've only used that maybe a dozen times in as many years working with the language (half of those incidents were during a single contract, but that's a story best left for another day). So why all of a sudden would I want that running in the background every time I save a design element?
I suspect the answer lies in the inner secret workings of the new Eclipse-based LotusScript editor (which rocks, by the way.... although I changed the font scheme pretty rapidly after upgrading because I find italicized code to be a huge pain to work with). Oddly enough, however, this behavior wasn't triggered while working with a design element that uses the new editor - script libraries and agents do, but not forms. After experimenting with it for a few minutes, I found that the reason for the conflict was that I had the script library open on another tab while I was updating the form. Apparently the "Use" statement in the form told Designer that the script library should be recompiled, but having that library open at the time caused Designer to think that every element referencing the library needed to be recompiled as well, including the element whose recent save had triggered the recompilation. This would cause an external modification to the design note I had open, triggering a conflict the next time I tried to save it.
Needless to say, I've disabled that preference for the time being.
As has been mentioned at great length elsewhere, Notes/Domino 8.5.1 is a brilliant release. Everything's noticeably faster and less buggy, and some very useful features were added. One of those features, however, caused me considerable grief yesterday, when I had occasion to revisit my dear old friend, LotusScript. Specifically, I was updating the code of a button on a form that referenced a script library - a very familiar scenario for most of us.
What was unfamiliar, however, was that Designer was generating a save conflict on alternating save operations. A save conflict, you say? In a design element? Indeed... in a local template, no less. A local template that doesn't even have a server replica yet. In other words, it couldn't be a replication conflict... it was definitely a save conflict. I was baffled... until I noticed some unusual chatter in the status bar indicating that the form had been updated by an auto-compilation process.
In 8.5.1, a new preference has been added: "Enable automatic recompilation of all dependencies". Sounds good, right? If I make a change to some script library, I want any design element referencing that script library to be using the new code. Except... it nearly always has. I haven't had to manually recompile my forms, for example, in order for them to be aware that I updated a script library they reference. This is Domino, after all... it just works. True, on very rare occasions (usually while working in a complex application that has a ridiculous amount of script libraries), I've had to resort to invoking the "Recompile All LotusScript" option in the Tools menu... but I've only used that maybe a dozen times in as many years working with the language (half of those incidents were during a single contract, but that's a story best left for another day). So why all of a sudden would I want that running in the background every time I save a design element?
I suspect the answer lies in the inner secret workings of the new Eclipse-based LotusScript editor (which rocks, by the way.... although I changed the font scheme pretty rapidly after upgrading because I find italicized code to be a huge pain to work with). Oddly enough, however, this behavior wasn't triggered while working with a design element that uses the new editor - script libraries and agents do, but not forms. After experimenting with it for a few minutes, I found that the reason for the conflict was that I had the script library open on another tab while I was updating the form. Apparently the "Use" statement in the form told Designer that the script library should be recompiled, but having that library open at the time caused Designer to think that every element referencing the library needed to be recompiled as well, including the element whose recent save had triggered the recompilation. This would cause an external modification to the design note I had open, triggering a conflict the next time I tried to save it.
Needless to say, I've disabled that preference for the time being.
Comments
By signature, I mean the subroutine/function names and parameters or the class names or properties.
So you could change the code in a subroutine all you wanted, but if you changed the name of the subroutine or the parameters, a recompilation was required.
Took me a long time to figure that out... (And maybe I'm STILL wrong).
Anyway, thanks for pointing out that the recompile behavior is a preference!
Posted by Jake White At 06:10:12 PM On 10/29/2009 | - Website - |
Tim, I can tell you why they do it even on stuff where you can't use the new editor. It's so they can flag errors for you in the Errors list. If you change, say, the parameters to a function in your library, and that function is used in 3 forms, 6 views and an agent, then you want those design elements to be flagged for you in the Errors list.
However, what's colossally dumb is that it saves the recompiled element back to the NSF even if it didn't need to. So if, for example, you didn't change the function such that the calling design element would break, then *DESIGNER SHOULDN'T WRITE THE CHANGE BACK.* It's totally pointless, and just creates replication traffic and opportunities for conflict when none is necessary.
This is yet another ill-conceived behavioral change on Designer. Now we have to worry about people working on backend script libraries overwriting the changes of people working on Form UI.
Posted by Nathan T. Freeman At 04:29:11 PM On 10/31/2009 | - Website - |