I like scotch whisky. I like the taste, I like the color, I like the way it sort of clings to the glass a little bit as you swirl it around. Unlike many purists, I will sometimes add ice, but usually just water. One of the things that fascinates me about scotch is that it doesn’t just improve with age. It actually needs to age to even be drinkable. Right after it’s distilled, and before it goes into a barrel, scotch whisky is completely clear in color and, apparently, tastes “brightly fruity and slightly solvent-like”. Yum. It’s the process of aging in the barrel that gives whisky its color and its mellow flavor - by law in the UK, scotch must be barrel-aged for at least three years. Some, of course, are aged a lot longer than that, and if you have a cool $25,000 to spend, you may be interested in a bottle of The Glenlivet 50 year-old.
Software, of course, doesn’t necessarily follow the same pattern. Once a software product has been around for 10, 15 or 20 years, it’s often considered long in the tooth and past its prime. One example we can all relate to, of course, is Lotus Notes -> HCL Domino which, despite languishing largely unloved in its latter years under IBM ownership, is enjoying a new lease on life now. Domino notwithstanding, many software products have a tendency to come and go as time marches onward. Anyone remember MacPaint? Wordstar? Bob?
While software products come and go, many of the basic functions that they perform persist. The humble search-and-replace feature, for example, has been around since the very beginning. Before the early 80s, graphical user interfaces (GUIs) were not really a thing, and so those of us who learned to program before that time used text based editors to write our code. (My first programs were written on punched cards, but we won’t go into that…) Vi was the first editor that I learned, which makes it pretty amazing that vi still exists in most implementations of Unix/Linux to this day.
My point is that, even in these very early versions of primitive text editors, one of the key features was considered to be search and replace. The ability to reliably identify every occurrence of a string within a text file, and then replace them, individually or all at once, has been baked into every text editor for more than forty years. All you had to do was to type
:%s/one/two/gto replace all occurrences of the string “one” with the string “two”. Easy.
Of course, back in those days, most of the programs we were writing were relatively unsophisticated. If you were interacting with a human, pretty much the only thing that person could do was to type something on the keyboard. But then, along came the GUI, and with it the mouse. All of a sudden that simple human could click. They could right-click, control-click, hover and drag. A new programming paradigm was needed, and along came event-driven programming.
This meant, of course, that your code was fragmented into little bits, each of which handled some random event that might be thrown at you. This was also about the time that Lotus Notes appeared on the scene, a platform that simplified the process of writing applications in this environment by handling a lot of those complexities for you. The Lotus Notes client allowed you to build forms that could contain fields and buttons, checkboxes and pick lists, and all of those UI elements had (formula) code fragments attached to them.
As time went on, formula code was deemed to be insufficient to meet the needs of developers who were attempting to build ever more complex applications atop the Notes platform. And so LotusScript was introduced and, not to turn this into a history of the Lotus Notes programming environment, the complexity of what was now called Domino Designer mushroomed.
It’s hardly surprising, then, that search and replace, that most basic of programmer needs, has been hard to deliver reliably within the Domino Designer environment. The basic search and replace feature within Designer has always been a bit, ahem, challenging to use. It’s admittedly hard to search every nook and cranny in the database design for strings, and then present them in context to the developer/user in a way that’s meaningful.
That’s why we built Teamstudio Configurator. Configurator integrates neatly into the Search dialog in Domino Designer (as an extra tab) and allows you to search for any string within the Domino database design or data. More importantly, it shows you exactly where it found a match, including a preview of the design element in question. And it includes all the lovely bells and whistles you’d expect, such as support for regular expressions and full logging. Configurator also respects the Domino security model and integrates nicely with Teamstudio CIAO! for version control.
To learn more about Configurator, click below. Search and replace has been around for a long time; building and maintaining applications in HCL Domino can be hard without a reliable, easy to use solution to that particular problem. So hard, it could drive you to drink. Cheers!