When I upgraded to ND6 a few years ago one of the things that jumped out at me the most was in the Designer Help - the “Language Cross Reference” listings. I swim in this product every day, and it’s nice to know that “UString” is similar to @Repeat.
But there is one area of cross-language capability that seems to be strangely missing from @Formulas – NotesViewNavigator capabilities.
I’m not talking about a complete re-implementation of the NotesViewNavigator or NotesViewEntry classes in @Formulas, but two simple things:
-
A way to retrieve a category row with totals in @Formulas. Either an extension for @DbLookup, or @DbColumn, or a new function altogether (@DbRow?)
-
A way to determine if the a particular document UNID is contained in a particluar view.
Thoughts? Ideas? Coming in ND8? 
Subject: RE: LotusScript <> @Formula cross-reference question - Andre?
It’s always nice when you can do your task in your preferred language. We do have to balance this against making the client too unwieldy in terms of disk size and memory use, and even more so, balance competing priorities for our developers’ time.
Speaking for myself, there are lots of things you can do with @Commands that I would love to be able to do in a NotesUIView or NotesUIDocument in LotusScript. However, I don’t get to create new methods just because I would like to use them.
The languages will never be equal – it pays to be good at all of them because they are each the best choice for some tasks. It also helps to be familiar with the ways to mix them (e.g. LS2J, using JavaScript to “click” a button that’s written in a different language, calling an agent, writing events in macro language and then doing something that causes the event to fire…).
Generally speaking, we need a more compelling case for language extensions than “it would be nice if we could do this without resorting to LotusScript.” What would this enable you to do that you can’t do now, or what would it make much, much easier? Why is it important to be able to do that? What functionality does it let you provide the end-user, that they will find valuable and will aid their productivity? In the end, it all comes down to value for the end user, and that’s how we have to justify things. Show us how Joe User benefits from this change.
Developer productivity is also a consideration, and it’s one that I advocate for, but there are a lot fewer developers than end users, so the key point for a potential customer is how does it help their users and their bottom line – and that’s where we focus our efforts. We’re already well ahead of the competition in terms of ease of development, whereas the choice in terms of end-user UI is not so clearly in our favor.
Subject: RE: LotusScript <> @Formula cross-reference question - Andre?
Thanks for the response, Andre. I’m definitely good at all of the languages and techniques used in Notes/Domino, and my question wasn’t to point out something that can’t be done, just something that requires jumping through a lot of hoops.
Here’s my exact scenario:
I’ve got a category total I want to show in a Computed-For-Display field on a document when a user opens it. And it needs to work on the web, too. This means:
-
Add the field to the form. Write the formula to compute to itself.
-
Write LS or Java to use the NotesViewNavigator class to find the category I want and extract the column value desired.
-
Add a WebQueryOpen agent that works with #2 and populates the field.
It would be a whole lot nicer to simply add the field and the appropriate formula, but it’s definitely not required to solve the problem. It would likely, though, save significant resources (particularly over the web) over running LS code.
I definitely hear your point about weighing development options, though - we do the same thing here. Developing a streamlined way to accomplish something you can currently do often takes a backseat to solving a problem that you currently can’t address at all.