In this comment it was noted converting arrays to ArrayList at the template level is hard
This PR does do it, though it's done within ViewableData::obj(), which was considered to be a bit too risky
Options provided were:
Update ViewableData::obj() to return arrays directly if there are any
Update ViewableData::obj() to wrap arrays in either a list or ArrayData depending on what type of array they are
Update ArrayList to either never wrap arrays, or to always wrap them in either a list or ArrayData depending on what type of array they are
Some combination of the above
Decoupling the logic from ViewableData - though that may be more effort than it's worth
Something else neither of us considered yet, if someone else has any ideas.
Acceptance criteria
Native arrays can be returned in PHP methods, and then iterated over in templates
Nested arrays can be iterated over at all levels
Changes outside the templating system are kept to a minimum
Changes outside the templating system are evaluated to see how wide-reaching their affect might be, and the changelog mentions anything worth mentioning
Associative array can be access via their keys.
PRs
kitchen sink CI run with the main framework PR installed (note the one CI failure is just because pulls/6/arrays-in-templates isn't identified as matching a supported version of Silverstripe CMS - it's only failing because we are using a fork in CI)
Related to https://github.com/silverstripe/silverstripe-framework/issues/11196
In this comment it was noted converting arrays to ArrayList at the template level is hard
This PR does do it, though it's done within ViewableData::obj(), which was considered to be a bit too risky
Options provided were:
Acceptance criteria
PRs
kitchen sink CI run with the main framework PR installed (note the one CI failure is just because
pulls/6/arrays-in-templatesisn't identified as matching a supported version of Silverstripe CMS - it's only failing because we are using a fork in CI)Alternate PR