You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The attr option of the formfields is misused to set arbitrary data to control the rendering in the template (input_group, simple_col, col_size and so on).
Besides semantically wrong (there should only be attributes for the rendered markup in it) it also breaks html validation since (at least with the current template, eg: {% block widget_attributes %}) all values in the attr option array are rendered as markup attributes.
Symfony doesn't allow arbitrary fields options as long as they are not defined in a Type or Extension, so i assume thats the reason.
So i Propose an FormExtension which just adds an (array) option, where we could put all the arbitrary data in which is needed by the templates. Thus getting a clean separation and we also won't every time need a new Type or Extension if we need a new option (unless this options needs other options set behind the scenes, like #290, but thats a different thing)
If that Extension is done, we should rewrite the template, but that WILL break backwards compatibility.
You thoughts on that?
The text was updated successfully, but these errors were encountered:
The
attr
option of the formfields is misused to set arbitrary data to control the rendering in the template (input_group
,simple_col
,col_size
and so on).Besides semantically wrong (there should only be attributes for the rendered markup in it) it also breaks html validation since (at least with the current template, eg:
{% block widget_attributes %}
) all values in theattr
option array are rendered as markup attributes.Symfony doesn't allow arbitrary fields options as long as they are not defined in a Type or Extension, so i assume thats the reason.
So i Propose an FormExtension which just adds an (array) option, where we could put all the arbitrary data in which is needed by the templates. Thus getting a clean separation and we also won't every time need a new Type or Extension if we need a new option (unless this options needs other options set behind the scenes, like #290, but thats a different thing)
If that Extension is done, we should rewrite the template, but that WILL break backwards compatibility.
You thoughts on that?
The text was updated successfully, but these errors were encountered: