I've got some legacy code that I'm trying to convert to modern code, because I'm sure the number of Appian developers left in the world who understand this are diminishing. Well, to update it, I need to be among them.
ri!selectedIndex << index(_, "selected", 0)
What does this mean?
ri!ruleInput << rule!myRule(_, ri!datasubset.identifiers, ri!datasubset.data) << index(_, "selected", 0)
What does that mean? Can anyone explain how to convert that into a!save function?
Discussion posts and replies are publicly visible
Doing manual saves in early SAIL was an enormous pain, as evidenced here.
Generally saveIntos only wanted to evaluate such that the "value" parameter ends up in the save target. I'm fuzzy on this, but I think this means if your saveInto has "ri!someText" as a target, it would be loosely equivalent to putting "ri!someText << _" -- the partial evaluation "_" refers to the "value" parameter of the interface object.
Then to get interface objects saving arbitrary other stuff, we had to trick the "<<" operator into pulling in other data, usually by passing it all into some expression rule. The one I used most often was an expression rule which would take in 2 inputs: _ and some other value, and then it would just spit back the second value and ignore the _. This essentially allowed you to pull off a manual "a!save()" operation without actually using a!save.
Per your first example with selectedIndex... it looks like they were maybe using the "index()" function to get a property (grumble) named "selected", and if none, to return zero. This value would then be stored in ri!selectedIndex. I'm not exactly clear here, it might be helpful to see how it's used in context.
Per your second example (assuming it's separate)... again I'm fuzzy but I think using multiple << operators worked sequentially backwards from the end of the expression, meaning the right-most piece would evaluate and pass into the "_" input of the middle piece, then that all would evaluate and save into ri!ruleInput. SO MESSY. I hope you find whoever wrote this and fuss at them. But for more complex logic this is the stuff we'd have to resort to back in the day (i was newer to SAIL back then so luckily I was spared much of this).
Hope this helps a little bit. One of my main suggestions would be, when convenient, *try* the functionality and observe what end result it produces, then rebuild that. This might be a lot more efficient than trying to exactly back-engineer the "<<" logic.
So helpful! Especially if I do go into the rules being called and find that the _ parameter is being completely ignored.
Appian was much like Macintosh back in the day. You didn't so much give it instructions as trick it into doing what you want. It's less and less that way all the time, but you still occasionally have to come at Appian sideways and catch it unawares.
Lol reusable rule named "ReturnFirstInput", anyone? Takes two parameters, value and projectedValue, code is as follows:
ri!value
That's the one.