Uses wrong repeat index from the radio button, but not from the form repeatformRepeatSplitLivingAnnuities[{{$index}}][test]. Maybe even it's by design and we could overwrite with dynamic name, but
Completely ignores dynamic name setting. Follow rendered code bellow.
It gets the $index from the closes repeat and that is the one on the checkboxes. To access the $index of the parent repeater you can use a value component and set the $index to an other variable name and access that from the child repeater.
Yes, now I know how to access "parent" repeat index (Get Nested repeat index) but problem is - Wappler overrides dynamic name binding so I can't use parent index.
You can see that I set name to be "record" but in rendered code Wappler is not using them.
Related to No1,
-we don't know what "test" is and its value
-First $index and then test... [$index][test]. Is this on purpose?
I would wait to see:
[0][0]
[0][1]
[0][2]
[1][0]
[1][1]
[1][2]
[2][0]
[2][1]
[2][2]
[test][$index] , suppose test is the outer repeat's $index value
Thank you for helping, but you didn't get the main problem.
It's not something I did - it's what Wappler generated when page is rendered. I set to use dynamic name attribute to be "record" but Wappler completely ignores that.
His code is correct, the formRepeatSplitLivingAnnuities[{{$index}}][test] is being parsed as a template string and is equal to 'formRepeatSplitLivingAnnuities[' + $index + '][test]'. This generates a valid input name that is being accessed on the server like $_POST.formRepeatSplitLivingAnnuities[0].test.
For accessibility I agree that he probably should have dynamic id and for attributes, when you click on the label of the second radio it will select the first due to the duplicate id's. But that has nothing to do with the issue he is describing.
The dmx-bind:value="id" seem correct for me as it is mostly used as a value for inputs.
test is not a value, it is the name for the input, as described in No1 it is a valid way for naming form inputs. Also test is not the outer $index, he expected the $index to be from the outer repeater instead of the current.
The problem is that Wappler input name generator doesn't handle nested repeats nicely and just uses $index always without knowing it is within a different repeat scope. It is also not directly possible to access the parent $index without creating an extra value component which can be referenced.
I created a variable within the formrepeat that is holding current form repeat item index: <dmx-value id="var1" dmx-bind:value="$index"></dmx-value>
Then in Radio Group Repeat I set name to be dynamic <input class="form-check-input" type="radio" id="selectSplitLivingAnnuitiesDependent_2" name="record" dmx-bind:value="id" dmx-bind:name="'record'+var1.value">
Unfortunately this approach didn't helped - Wappler overwrites it.
@patrick Is there any chance to see fix/workaround for this or it's better to use different approach like selection element instead of radio group?
Thank you for the more detailed example. I was thinking Wappler generated the name expressions but it is actually the form repeat component that does that. Not sure if it will be easy to fix but will have a look at it.
Would be possible to make a lookup and check - if this particular repeat is under form repeat and for the name use form repeat index instead of current repeat index?
I have stopped using the form repeat component (unless I need sorting), instead I'm now using standard repeat or repeat-children ones. I have a bit of extra work in setting up dynamic attributes such as id, for and name but I have full control over them. As a workaround, if the current behaviour is causing you issues at the moment when nesting form components, it is quite effective - at least until @patrick pulls a rabbit out the hat and improves it!
I've updated the code to also generate a $formindex within the scope data which will be used instead of the conflicting $index. That should theoretically solve the problem.