[FEATURE] Allow setting keys of objects

[spthiel]

Add an additional option to set the name to a period seperated path for modifying of inner values of arrays/objects for the ability to expand objects during fluid template validation

An example usecase for this would be when rendering a partial for a range input and allowing the passing of min and max as seperate parameters to additionalParameters to the f:render to then merge them inside the partial like this

Template.html

<f:render partial="RangeInput" min="0" max="100" additionalAttributes="{data-target: "rangeinput"}"

RangeInput.html

<f:variable name="additionalAttributes.min" value="{min}" />
<f:variable name="additionalAttributes.max" value="{max}" />
<f:form.textfield type="range" additionalAttributes="{additionalAttributes}"/>

This change allows for the parent to be null so in above example the additionalAttributes key is optional and if not passed the resulting additionalAttributes array would just look like ["min" => 0, "max" => 100]

[spthiel]

Saw today it's included in #425

[spthiel]

Reopen as #425 was closed for the scope being too large

[s2b]

Did you try what happens if additionalAttributes is a PHP object? I suspect that you solution wouldn't work in quite a few cases, it probably throws PHP warnings there.

In my opinion, this should only be added if we can cover (almost) all cases we cover with variable access. This would mean for example to look for object setters. And I'm not sure if it's a good idea to allow Fluid to write data into domain objects.

[spthiel]

I definitely want to avoid anything that mutates data outside fluid (i.e. php objects) the goal of this is exclusively to allow for setting of further keys on fluid template variables

[NamelessCoder]

See #396 (would allow array union with + operator in variable accessor syntax).

IMHO, it should not be allowed to modify properties of already-assigned variables. It's fine to replace the objects (read: arrays only, not actual objects) and it's fine to assign new objects, but modifying the existing ones is not desired. Hence, the array union operator is pretty much ideal as it creates a new combined result from two array inputs with overrules in case of key match.

[spthiel]

I can accept array union as a solution to this issue