-
-
Notifications
You must be signed in to change notification settings - Fork 372
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Documentation][UF5.1]Input Arrays and Fortress #1251
Comments
I think this is the real issue here. It makes sense to me that both The same logic should be applied with transform. They should obey However, I did test the multidimensional arrays. Something like this :
And this exception is thrown : So second issue. |
Alright... It took all my engineering skills, but I think I got it. I added a bunch of tests in 2dd8d72 to go through many InputArray and Multidimensional Array scenario :
You can check out the Multidimensional.yaml and InputArray.yaml as an example of how this is implemented.
This is also fixed. If you find another scenario not tested, I'll add it. I'll review the doc when I get the chance and release the fix then. |
Fix released in Framework 5.1.1 👍 |
Input arrays
Years ago when I was first exposed to PHP, I learned about input arrays.
In a form, you can give multiple
<input>
elements the samename=
attribute, if it ends with (or just uses?) PHP's array notation, such as<input name="AllTheseInputs[]">
.If your page dynamicly generates rows of input fields, it's much easier to use an array
Input[]
than having to trackInput1
,Input2
,Input3
(etc) --and when you parse<input name="AllTheseInputs[]">
, PHP treatsAllTheseInputs
like any other array.Fortress
Now, what happens when we try to transform and validate an array like that in Fortress?
Validators
The Fortress
/learn
page says the validation step is built on Valitron, and the usage notes there say it supports dot notation with*
wildcards.Given an input array
SomeInput[]
, this lets us validate each element by usingSomeInput.*
in our Fortress schema.Validations against the base array
SomeInput
will instead test against the array itself--so we can use therequired
or the (undocumented in UF)array
validators here.Transforms
Manual testing on a small UF install shows that transforms are (silently) not applied using the Valitron element format
SomeInput.*
.However, if we use the standard format
SomeInput
, the transform is applied to all elements.Whitelisting
I did not test how whitelisting is applied to arrays, but the above demo shows that CSRF fields are stripped by Transform when they are not included in the schema.
If an input array will be sent through Fortress on the server side, it's probably good practice to use
require
and/orarray
validators on the array object, and this should be enough to whitelist it.Updating the schema in the above demo should be easy enough if additional testing is needed on this point.
Sample YAML schema
Putting all of this together, we come up with a schema something like this to validate and transform
<input name="InputArray[]" ...
:Disclaimer
Much later in
/learn
, there's a mention thatin UserFrosting, forms are usually submitted via an AJAX request
.I don't have experience with AJAX yet, so I don't know whether input arrays are as useful there.
If not, it may be worth an earlier mention instead? "If you were thinking of using input arrays, please stop and consider this other method that we'll explain in detail later."
Currently, Fortress is shown in chapter 8-f-1 vs AJAX Forms in chapter 15-d-1. That's quite a lot of material between the two concepts!
Multidimensional Arrays
I also did not test multidimensional arrays, as they're outside of my personal use case and it felt like setting one up in my display Twig might be excessive.
Valitron already supports them via dot notation, so our validators are fine.
At some point we may need to check how Fortress Transforms treat them, and update either Fortress or
/learn
appropriately.The text was updated successfully, but these errors were encountered: