From: "Adrian Crum" <adrian.c...@sandglass-software.com>
I'm working on the Mini-language <set-current-user-login> element, and I wanted
some feedback about this TYPE of operation.
Background: There are some things in the Mini-language script execution context that, from my perspective, should be read-only.
Some of those things are the delegator and security credentials (there are others - see SimpleMethod.java, line 85). From a
scripting standpoint, I believe it helps the developer if those things are constant or immutable, and provide a means to override
them explicitly in certain circumstances. In other words, the scripting language should be designed in a way that facilitates
writing good scripts.
Giving the developer the ability to override those things opens up the potential for quirky and possibly unsafe code. Changing the
delegator or user credentials mid-script might seem convenient at first glance, but it becomes a debugging and code maintenance
nightmare later on. There is a better way to handle the need to use different artifacts during script execution. For example,
instead of changing the script's delegator, entity operations could support specifying the delegator to use. The explicit use of
an alternate delegator is easier to understand and debug than a delegator change that occurred somewhere else in the script
execution path (a path that might include other simple methods).
The same thing could be done for security credentials. The Mini-language schema says the <set-current-user-login> element "...is
mostly used for calling services, etc" - but you can provide an alternate UserLogin to the service via the IN attributes.
Therefore, that element is not necessary.
A lot of existing Mini-language code performs those mid-script artifact changes, so this isn't something that can be changed
overnight. What I propose is a "best practice" where that type of operation is discouraged in the Mini-language documentation.
Maybe in a future version of the grammar, elements of that type can be deprecated.
What do you think?
Those ideas seem sound and well founded to me. We could already deprecate <set-current-user-login> since we can pass the login. We
have to make those changes very explicit though. Normally this one (<set-current-user-login>) is known anyway...
Jacques
-Adrian
