• State Not Answered
  • Replies 6 replies
  • Subscribers 8 subscribers
  • Views 3783 views
  • Users 0 members are here
Related Discussions
Home » Discussions » User Interface

I have a question on how the local variables in a load expression behave when th

georgej
I have a question on how the local variables in a load expression behave when the expression is invoked from SAIL (which are at times TEMPO SAIL Dashboards).It took long time for analysis as the issue was causing several production issues. Let me try to explain the issue with some a SIMPLE SAIL and Expression Rules. Attached is a simple SAIL which has a one section layout. When you enter input "IndSection1" text box and change the date value in "End Date Field", "Tst_LoadIssueExpr" (code snippet is below) is invoked and result is shown in "ResultSet" text box.
When you change the flip the value in "IndSection1" between blanks and non-blanks, as expected the Boolean result displayed in "ResultSet" text box is not changing. But if you modify the below "Tst_LoadIssueExpr" ri!input directly rather than saving to a local variable ,the result shown is as expected.
Can anyone explain what is causing this weird behavior. In actual production code ,this is a n...

Tst_LoadIssues.txt

OriginalPostID-171957

OriginalPostID-171957

  Discussion posts and replies are publicly visible

  • 0
    ...ightmarish as we have lot of grids getting displayed in a TEMPO report which doesn't refresh based on user interactions.

    Tst_LoadIssueExpr:- simple rule ,it is as below
    load(
    local!input: ri!input,
    if(
    local!input = fn!true(),
    fn!true(),
    fn!false()
    )
    )
  • 0
    Certified Lead Developer
    Understanding load() and with() are 2 of the most important principles in SAIL and I suggest you study the docs in detail on these. Variables defined in load() are only evaluated once on 1st execution of the expression and as such should only be used for static data and saveInto targets, it should never be used in a sub rule as you have in the example instead use with() to define variables that need to be re-evaluated. with() also has performance benefits over load()
  • 0
    Thanks for the inputs Tim, every time the sub-rule is invoked isn't a fresh execution of the same. Could you please guide me to any documentation which specifically talks about how load() behaves in a sub-rule. The issue here is ,when you have a complicated report ,which has multiple girds being displayed depending on user action, it is not possible to modularize the same as separate SAIL rules. Grid requires load() variables and they are not refreshed. Is there some best practice on modularizing SAIL components while making complicated reports
  • 0
    Certified Lead Developer
    forum.appian.com/.../Evaluation_Functions.html
    Nothing specific about sub-rules but I believe paragraph 3 of the notes section is describing your scenario particularly around context. I assume you have tried replacing load() with with() in your example to see that it works. Grids require a pagingInfo which has been defined in a load() but this should be defined in the parent SAIL rule and passed down to your sub-rule where your grid is defined.
  • 0
    Tim,there you go...issue is right there.In a tempo report,you define paginginfo in parent SAIL using load and then try to pass it via parameter.Problem is from the second call onwards the paginginfo data is never refreshed ,but it takes the value of previous call.This creates lot of erratic behaviour.Now,if you try to declare the paginginfo in with(), immediately you sort/page the grid ,SAIL form breaks with obvious error message.I don't think the non-refreshing nature of load() variables in a sub rule is a feature,but rather a bug in product.Due to this issue you are completely handicapped from modularizing SAIL components in complex TEMPO reports.Finally you end up writing huge monolithic SAIL forms which are quite difficult to maintain.
  • 0
    Certified Lead Developer
    Defining complex reports is always challenging, if you can provide more details I'm sure you'll get plenty of advice. It sounds like you're showing multiple girds on your report and using some sort of button/link/dropdown to hide and show certain grids? Keeping control of your pagingInfo parameter is tricky in these scenarios as you can end up with various errors such as the startIndex being greater than the total count. You can use just one pagingInfo parameter of define one for each grid, the key aspect is resetting the pagingInfo everytime you navigate to a different display. If you are using one of button/link/dropdown to control which item to display you should reset the pagingInfo as the 1st save statement e.g.
    saveInto: { a!save(local!pagingInfo, topaginginfo(1,10)), <your dynamic control variable>, .....}
© 2024 Appian. All rights reserved.
We want to hear from you! Submit a review on Gartner or G2.