I've been working on a user registration "component" for a Domino database. Something to let users register for access and then, once logged in, change their passwords.

As part of both processes the password entered is validated and checked it's of a certain quality. It has to be a certain length as well as containing both uppercase and lowercase letters along with some numbers. So, "P4ssw0rD" is ok but "p4ssw0rd" and "P4SSW0RD" aren't.

It's not that I forgot about it. It's just that there's an LS equivalent to the @Function I'd used and, in that case, you'd like to assume, there'd be no need for Evaluate(). So I went down the pure LS path. Once I'd got to the point of no return I didn't even consider evaluate().

Also, yes I'm a purist and hate to use Evaluate unless there's no alternative.

And here I thought I knew you so well. All the righteous hacks to get Domino to behave that you've taught us over the years, I figured you'd be the furthest thing from a LotusScript purist. I can't get it to do my job for me without liberal and judicious abuse and misuse. I suppose my LS function from years ago that wrote a vbs file for some bailing-wire automation would receive a level stare from you. ;-)

Not to wax apologist, but you know using Evaluate in some circumstances can yield substantial performance benefits... LS2J instances should always be kept to a minimum though or you're just begging for sluggishness.

If using the whole alphabet trick hadn't worked then I'd have "happily" gone for the Evaluate method instead. I just try to avoid it unless completely necessary and all avenues have been exhausted. It feels awkward and cumbersome having to dim the variant and all that malarkey.

I've done quite a bit of performance testing, and found that in a majority of cases evaluate() is faster (by far) than doing the same thing in Lotuscript. Lotuscript is always interpreted where Evaluate() calls a formula language processing api which is compiled. In one test case, I compared @password() for creating hash to an actual lotuscript written hash algorithm, and the rest was hundreds of times faster in evaluate.

Another advantage, as in this case, is that you increase the chances of a bug (yours or lotus's) that would result in your two code paths having a different result when you need to perform the same routine in both languages. Less code == better code.

actually - evaluate() and @Eval can be very very useful if you want to be able to modify your rules in *one* place without having to modify the code in several places and if you want to be sure that the exact same code is executed (which is perhaps preferred and a bit beautiful in a situation like this? (keep the rules in one place)) imho at least.

Just store your @Formula expression in a doc, retrieve it from the executing code and run it via @eval/evaluate().

Anyway, there's one thing I find much more annoying when working with "real" (read: DD entry) user registration attempts. I never know when and if Domino will really pick up the account and in particular any group memberships.

Maybe it's only me, but to date I have not found a reliable way to send out a notification message to the new registered users at a point in time, where I can be absolutely sure, that the new account is fully functional. If you have available any magic tricks here, let it flow.