Hey,
I've been wondering about how partial functions can be used in Appian.
One thing that I was looking at was sticking a bunch of them together to define validation functions by passing them as arguments like this:
a!textField( value: local!value, saveInto: local!value, validations: rule!BLAKEJ3_Validation_Composer( rules: { rule!BLAKEJ3_Validation_TextIsLongerThan10Chars(_), rule!BLAKEJ3_Validation_TextIsShorterThanGivenLength(fieldLength:25, input:_), rule!BLAKEJ3_Validation_TextMustEndInFullStop(_), rule!BLAKEJ3_Validation_ApplyBySentence( rules: rule!BLAKEJ3_Validation_SentenceMustStartWithCapital(_), input: _ ) }, input: local!value ) )
This seems like it can be very readable and it breaks testing down into smaller bits that can have defined test cases in expression rules. It means that new validation rules can be assembled from shared modular rule components. However I'm also wondering if its over engineering for the vast majority of cases and if most validation is such simple functions that those aren't really relevant benefits.
I'm curious for more opinions about this as well as hearing how other people have used a very uncommon Appian function.
E: This crashes every time I try and add a tag
Discussion posts and replies are publicly visible
The basic idea is to get a placeholder so the function won't crash due to lack of the input, even though you don't have the input yet. Just wait a second while I get this input for you, you say. It doesn't matter the vast majority of the time, because you have to define the input immediately afterward. If you have to define it anyway over here, why don't you just define it over there?
A few of the looping functions require this. Apply and ApplyComponents were the biggest users, but they're now basically worthless thanks to a!forEach. The all() or any() functions might still be useful sometimes, but the reduce() function still gets used a lot. I even used reduce() in an a!forEach one time.
How the documentation says apply works on a function with 2 parameters: apply(fn!function, local!arrayOfInputs, local!sameParameterEveryTime)
How it actually works (which may have been too advanced for right there in the apply article): apply(fn!function(_,_), local!arrayOfInputs, local!sameParameterEveryTime)
What's the difference? Using partial evaluation, I can choose which gets iterated over and which doesn't, and I can hard code the one that doesn't change right there: apply(fn!function(local!sameParameterEveryTime,_), local!arrayOfOutputs)
Until you know how to partial evaluation, it's impossible to use apply on a function where you need to iterate over the second parameter only. Imagine if you had 3 parameters, and the first and third needed to be iterated, but not the second? Is that even possible?
apply(fn!badFunction(_,local!sameParameterEveryTime,_), merge(local!firstParameterList, local!thirdParameterList))
You'll also see partial evaluation in the code generated by the report builder to look at as well.