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
  • You can use the fn!index() and use the 'name' of the name/value pair (rather than the index number) as if you were asking it to search the dictionary e.g. fn!index(<myData>,"estadopedido", null). Note that the third parameter is what will be returned if the search does not find what you've asked for. Here's an example:

    a!localVariables(
      local!myDictionary: {
        item: 1,
        description: "Widget",
        color: "Green"
      },
      fn!index(local!myDictionary,"color",null)
    )

    returns:

Reply
  • You can use the fn!index() and use the 'name' of the name/value pair (rather than the index number) as if you were asking it to search the dictionary e.g. fn!index(<myData>,"estadopedido", null). Note that the third parameter is what will be returned if the search does not find what you've asked for. Here's an example:

    a!localVariables(
      local!myDictionary: {
        item: 1,
        description: "Widget",
        color: "Green"
      },
      fn!index(local!myDictionary,"color",null)
    )

    returns:

Children
  • a!localVariables(
      local!myDictionary: (index(a!queryEntity(
        entity: cons!GP_Pedido_Entity,
        query: a!query(
          selection: a!querySelection(
            columns: {
              a!queryColumn(
                field: "estadopedido"
              )
            }
          ),
          logicalexpression: a!queryLogicalExpression(
            operator: "AND",
            filters: {
              a!queryFilter(
                field: "nombrepedido",
                operator: "=",
                value: ri!nombrePedido
              )
            },
            ignoreFiltersWithEmptyValues: true
          ),
          pagingInfo: a!pagingInfo(
            startIndex: 1,
            batchSize: -1
          )
        ),
        fetchTotalCount: false
      ).data,1))
      ,
      fn!index(local!myDictionary,"estadopedido",null)
    )

  • 0
    Certified Lead Developer
    in reply to Stewart Burchell

    To be honest, I'd much rather we teach people to use property() when fetching a property, and reserve index() for when they want to fetch a position (i.e. index) within an array - seeing people use index() everywhere and indiscriminately, and often nested on top of each other doing different things, absolutely kills code readability in the long run.

  • I think I've seen you comment on this before. I've just checked and they appear to be identical in their functionality - bot will take a position or a property name for their second parameter. Is your assertion is that we use index() for positional, and property() for name/value searching purely because it makes the code more readable?

  • 0
    Certified Lead Developer
    in reply to Stewart Burchell
    Is your assertion is that we use index() for positional, and property() for name/value searching purely because it makes the code more readable?

    Exactly.  Having combed through code where there are nestings 3 or 4 deep all using index() when some are positional and some are property fetches, I find that it makes a pretty severe impact.  Otherwise, why bother having both functions?

  • 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