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
For consistency, entry partial for controller behaviors should be called "container"
Added addViewPath() method to ViewMaker
Remove "fa" from icon docs (not necessary)
Fixes#2439
It would appear many plugins incorrectly use type: relation as a list column, when this does nothing. Previously it would fallback to the text type, now that invalid types fail hard, this adds a softer landing by spamming the trace log instead.
Refs #2438
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
Priit Perna
Quezler
CSNWEB
Samuel Georges
Luke Towers
Aleksey Bobkov
Pásztor Gábor
Trias Nur Rahman
joseph-d
Joseba Juániz
Szabó Gergő
Anže Časar