Change of token when running through a loop

@coreteamvn I had to modify the model to reproduce the problem, i.e. link to the gateway from the "Start display" and unlink and re-link the "After loop display" so that it gets executed afterwards. Then I was able to reproduce the problem.

Before we dive deeper into this, could you please try to reproduce this in a simpler version of the model, i.e. without third party modules like datafield and field_permission? If the same issue happens with e.g. a multi-value simple text field as well, then we can dive into the list logic and see what's going wrong there.

Hi Jürgen!

On a clean install i tried it with a multi-value text field (field_text_test).

Two things I noted:

a) Should the content of the multi-value text field not be visible in a ECA display message? In the original posting, the more complex multi-value datafield shows up in the display message (node:field_testtt). Ive tried to show the content of the multi-value text field with "node:field_text_test", "entity:field_text_test" and specifically loaded the node (current scope) ("loadedNode:field_text_test"). In the ECA message nothing shows up (neither before nor after setting tokens); the token that is used later to loop through the multi-value text field and pop items off is correctly populated though.

b) When is the submit form model/event actually triggered? I'm asking because when I want to add a new element to the text field (so before clicking "save") and the ECA loop is (incorrectly) not limited by the >0 condition at the start of the loop, the loading icon to add a new row is permanently showing "Please wait". I thought the event is triggered when one actually clicks the save button (and not already when one wants to add new text values).

Should the content of the multi-value text field not be visible in a ECA display message?

That depends on the field type. When a message is displayed that contains a token, e.g. [node:field_text], then Drupal's token system searches for the value of that token and uses its string value to be replaced in the message string. The programming of the field type is responsible for what it returns when Drupal asks for its string value.

When is the submit form model/event actually triggered?

That depends on the form. A form can generally contain a lot of submit "buttons", not each of which might be looking like a button even.

So, if you want to continue testing with this so that we can get to the ground if this, you may (a) be using debugging instead of messages to see what value each token has at each step and (b) you may consider if form submit is the best event. Not only because of the ajax posts that get into your way, but also when you're using the node field value, you're most likely using old values from the node and not those from the form, because the node will not be updated at that point. The event Presave entity might be more appropriate in this situation.

When using the action "Token: set value" with another token that already exists, then this action behaves like you set a new alias for the already existing token. When you refer to a node's field to be set as token value, then this action refers to that field. That means, if you then remove an item from the list, you remove it from the node's field.

The described behavior of "Token: set value" makes sense. It can be used to set an ambiguous "node" token to a concrete name like "article" without losing the reference. Plus it can be used to collect multiple objects into one collection. We use that mechanic already for collecting multiple entities and save them all at once using "List: save data".

On the other hand, the action "Entity: get field value" usually takes care of reading out field values and putting them into a new list. However it seems that it's (currently) not capable of supporting your multi-column field as it usually only reads out the main property values.

A possible workaround could be using "Entity: create new" that is of the same entity and bundle as your entity in scope. Then set the field value on that new entity, using [node:your_field] as field value. After that, you can loop over the field of the new entity, removing item by item, and this shouldn't affect the other one.

That means, if you then remove an item from the list, you remove it from the node's field.

Hmm, but then the field should be empty afterwards, when looping through the list and dropping each value one by one. However, it rather looks like the order of items is different afterwards, isn't it?

I haven't analyzed in detail what the example model posted here does. I only saw that "Token: set value" and "List: remove item" are being used, and thought it's worth noting the behavior when referring to an already existing token. As it seems it was assumed that "Token: set value" is copying values, which it doesn't.

Hi!

Thanks for the input - i set the log level to debug now and try to do some more testing on the weekend.

I made a custom module with datafield handling the few workflows. Most of the things work very well with ECA and datafield - considering the complex structure of datafield (one subfield is even an entity reference field in my case). the only thing i could not manage to implement so far was adding/appending a whole new set of subfields at once. looping through and setting different values worked very well when adding a [deltacounter] and setting/targeting the subfields.

One thing i misunderstood was indeed how the "set tokens action" actually worked. I thought it would leave the original value unchanged and would make a copy of the values. this certainly might have something to do with the behaviour. i also noticed the "content lock" feature kicked in quite often when testing.

i tried the submit event, because the update event gets triggered very often. troublesome when you are not careful and working with loops. had to resort to "change php version" on the shared host to "kill" any background processes.

i will give the pre-save event a shot.

This token reference back to the source only applies to objects, not to scalar values like strings, integers or the like. Is that a correct @mxh?

There is no distinguish of scalars / objects or other types. ECA's token system only accepts entities and DTOs as possible token data. Passed scalars, arrays and other sorts of objects are being wrapped with a DTO by the token service.

However, most actions are setting token data. For example, when calling "Token: set value" multiple times on the same token, it always replaces the existing one with another one. Exceptions are "List: ...", "Save entity" and probably a couple of others - they operate directly on an existing token. Such actions are usually meant for entities / lists and not for texts / numbers etc.

In #7 I talked about existing tokens. I have to be more precise on this: I meant concretely available token data. There are global tokens like "[site:name]". They are kinda available too, but they're not set as token data.

That's probably a bit of a mix-up, as we are using tokens for both the core's token mechanics, but also for setting our own tokens on runtime within ECA models.

@coreteamvn is there anything left for you to be clarified or can we close this issue?

Hi Jürgen!

All good from my side, I needed to resort to a custom module for a minor part of the workflow.

Thanks

Automatically closed - issue fixed for 2 weeks with no activity.