How get the value from a dictionary?

Hi,  I have a question how can I get the value from a dictionary?

e.g. Status: "enable", how can i get only the text?

in this image how can i get the text "enviado"?

And the value of a list of dictionaries with a specificied key?

  Discussion posts and replies are publicly visible

Parents Reply Children
  • I'm also a huge fan of code readability...but having nested property() would be no different from having nested index()...that's just bad to read either way...I'd prefer to use fn!reduce() and then call the relevant function with a list that represents the hierarchy you're drilling into...that's a much easier way to read what's actually happening:

    a!localVariables(
      local!myNestedArray: {
        order: {
          orderId: 1,
          items: {
            {itemId: 1, name: "Circle", color: "blue", quantity: 5, cost: 123.45},
            {itemId: 2, name: "Circle", color: "green", quantity: 3, cost: 99.99}
          }
        }
      },
      fn!sum(
        fn!reduce(
          fn!property,
          local!myNestedArray,
          {"order","items","cost"},
          null
        )
      )
    )

    ...and if you're mixing positional with named property then I guess your between a rock and a hard place as to whether you use property() or index()...but at least it would be most readable this way...

    ...and if you think about it a bit more this could become a generic helper rule, where you pass in the data, the hierarchy you want to drill down into, and what to return if nothing is found and the rule does the rest. 

  • 0
    Certified Lead Developer
    in reply to Stewart Burchell

    At the risk of beating a dead horse...

    I just found this doozy within an expression rule in the system I currently maintain - the use case in general terms is that it digests a nested CDT rule input, and outputs name:value pairs for use in a PDF document generation.  IMHO this is a nightmare of nested index() calls (and neither as uncommon nor as easily-avoidable as you suggest).  In this case, 2 of the index() calls are referring to indexes and 2 of them refer to properties.  This construct appears 5 or 6 times within the expression rule in question, each time just getting a different low-level property of the nested array.

    Yellow highlights are indexes, orange highlights are instances where property() should've been used IMHO.  I continue to be baffled why we aren't stressing that people use the appropriate function for code clarity when the proper function is available, documented, and has no downsides to its use.

  • I find myself reaching for the gin bottle (other analgesics are available!) when I see code like this...firstly because it should probably be encapsulated into a helper rule (this fragment appears at line 99 so there's way more code in this ER than just this!), and secondly because it's just impenetrable! At the very least there should be some comments to provide some explanation, and it's just so ugly/inelegant! Add in the anti-pattern of the cons!CONSTANT[hardcoded index] then this is setting up for future failure. 

    It would be interesting to see how you think it should have been constructed, Mike. It's a great learning vehicle...

  • 0
    Certified Lead Developer
    in reply to Stewart Burchell

    Agreed all around.  Ironically in this case, this *is* the helper rule.  I tend to agree that further encapsulation / mess obfuscation would've been good, though not being able to speak for the original dev team, my only guess is that it may not have been worth tons of extra effort to do seeing as this is a one-off PDF generation rule used in one document generation node using its own unique nested CDT.

    I assume that here, they wrote the code needed to get one property of the internal nested CDT array, then copy/pasted it 5 times over to get the others of the same nature.  They didn't make use of local variables to the extent that I probably would, though I don't have time to sit down and pattern-analyze it to figure out what would be best in the case of this rule.  [Also, seemingly to further decrease the code's readability, they auto-formatted the rule, which of course shoehorns in linebreaks where they aren't needed, and removes extra linebreaks where they were needed (for readability), etc.]

    But that's all tangential to my original point about index() versus property(), which I stand behind Wink