Converts a field name in the form of `model_json_attribute[subproperty]` to the dot syntax version used by validation rules `model_json_attribute.subproperty` for more accurate checking of the validation rules in the form widget.
See #2749, #2750 & #2751 on notes for how to better handle this. Put simply, the control of disabled VS previewMode should be given to the individual form widget, as opposed to the spawning parent.
Adds support for the `disabled` property to FormWidgets so that they will match the behaviour present in regular FormFields. Fixes#2724 and a personal annoyance of mine :)
This pipes all event calls through a new EventEmitter trait, which substitutes the October Rain event emitter trait. The view event has been moved to this trait also.
Pass some variables by reference to allow multi-extension.
Fixes#2420
- Using a proxy field would populate a relation with an array of attributes, this is not good or consistent. Instead the FormModelSaver trait is used to bring the behavior in line with FormController and others. This should improve consistency in the behavior and developer expectations.
- The noticeable difference will be that relations and their values are now set by the postback data where possible. In cases where this is undesirable -- eg: updating a relation triggers proxy fields to update with existing values, when they should seed from the relation instead (desire to lose prior changes) -- the formExtendRefreshData controller override can be used to prune the existing values from the dataset, where they will then be seeded from the model as normal.
- Also the $data property is only rebuilt if it differs from the model. Previously it would corrupt the model-based dataset by converting to an array then back to an object. If the two objects are the same, they will be passed by reference and values will replicate this way.
This is useful when a form renders another form inside, specifically the repeater. In these cases the model and data will diverge, and it also provides an opportunity to not apply extension logic to nested form fields.
Fixes#2257
This is useful when the model is unreliable, because it is not always populated with the relevant data set. This argument is only needed in edge cases, like when using a repeater or other split class<->data scenarios
Refs #2235
Just like DatePicker, relation and even regular fields should omitted from the data set
The same logic should apply to hidden fields
Fixes#1827
Recompile assets
Form fields are already constrained by their fields.yaml definition (values not defined in the yaml will not be saved) so we don't need to double dip by enforcing fillable too.