Remove the need for x in the variable name column

[BryceStevenWilley]

Realized today that we can simplify the story table a lot by providing us with more information from docassemble.

We need to trigger value because generic objects don't show all of their information when being sought, just the x.sought_attribute. However, if we are on a generic object screen, we can just directly include the x.instanceName in the DOM, the same way we include the user_info().variable:

    <div data-variable="${ encode_name(str( x.instanceName if defined('x') else '' )) }" 
        id="al_generic_object" aria-hidden="true" style="display: none;"></div>
    <div data-variable="${ encode_name(str( i if defined('i') else '' )) }" 
        id="al_generic_index" aria-hidden="true" style="display: none;"></div>

This gives us the exact name of the x object (x.instanceName must be set in order for DA to seek it). This means that Kiln can take this value and substitute it with the x.sought_attribute on the page, giving the correct value of my_var.sought_attribute.

Much of the same above goes for i and j as well.

The only potential historical issue that relates to this that I can find is #158 (comment), but I don't think that affects this?

Need to think through all of the combinations of things as well, but this does seem promising.

[plocket]

I agree this sound promising! The picture is complex enough that I'm not completely sure of the possible pitfalls. It seems like a solution that could really simplify the story table and take us into v5. We'd remove the need for the trigger variable completely.

Just fyi, we could contain all that data in one div, just using different data var names. E.g:

<div id="alkiln_proxy_var_names"
    data-generic_object="${ encode_name(str( x.instanceName if defined('x') else '' )) }" 
    data-index_var_i="${ encode_name(str( i if defined('i') else '' )) }"
    aria-hidden="true" style="display: none;"></div>

The following is true of our code even now, but may be especially relevant to this issue: I think to be fully effective this may need the loops worked out for fully digging into var names (#574) and, possibly, also need or be aided by #573 - avoid too much decoding.

[plocket]

Instead of breaking into v5, we could just add a new Step for this two-columns story table. As @BryceStevenWilley pointed out, we'll probably need to do some abstraction to avoid a bunch of fragile duplicate code.

[plocket]

[Answer: I believe it goes up to 'n']

Note for (near?) future self: we need all the index vars. Do they go beyond 'm'? Look in the da core code. We can be explicit or use a loop similar to the below:

<div id="alkiln_proxy_var_values"
  data-generic_object="${ encode_name(str( x.instanceName if defined('x') else '' )) }" 
  % for letter in [ 'i', 'j', 'k', 'l', 'm', 'n' ]:
  data-index_var_${ letter }="${ encode_name(str( value( letter ) if defined( letter ) else '' )) }"
  % endfor
  aria-hidden="true" style="display: none;"></div>

[Actually, going to take myself off this for now. This will take a while and I'm working on some other things.]

[plocket]

Below, I assume that users can and will do anything

x

Test for detecting and replacing x: /(^x)(?=\.|\[)|(^x$)/ /^(x)\b/.

This may not be enough. We need to test if someone can do something like set both of these on the same page:

fields:
  - Age: x.age
  - Is one of the best: best_people[x.name.first]
    datatype: yesno

Is that possible? It would be an unfortunate use case. We'll have to try it out.

Update to the above concern, these are all things I tried that caused errors:

  - Is one of the best: best_people[x.name.first]
  - Is one of the best: best_people[${ x.name.first }]
  - Is one of the best: best_people['${ x.name.first }']

i etc

Test for detecting and replacing i (global flag): /(?<=\[)([ijklmn])(?=\])/g. [Or /\[([ijklmn])\]/g if we don't mind having multiple matches along with our capture groups. Probably depends what methods we use.]

Does it need to be global? I'm thinking of a situation where we're setting a var like foo[i].bar[i]. In most situations probably not good practice, but I believe it's possible.

Procedure ideas for two-column solution

We need to keep our same decoding and list of guesses, but as we decode we can check for proxy vars. If we find them, we replace the proxy vars with the actual vars (that the user puts in the column labeled var). Also, if we do find a proxy var we can replace, we can get rid of previous guesses. After we've replaced all proxy vars, we can stop guessing.

[plocket]

We ended up not needing a new Step at all because we were already handling 2-column tables to have backwards compatibility with our first couple versions of the Story Table. These new changes shouldn't interfere with those, but

1. We're not supporting those versions of the Story anymore
2. I believe no one is actively using those versions of the Story anymore.

An all around win, I hope

[BryceStevenWilley]

I missed that this was closed, but I'm super happy you got to this! Thanks a ton, you did a ton of great work to push this to the end.