You are right that latest change is not sufficient to address the issue, but I fear the fix will need to be more involved:
currently, for most form widgets. the attributes contained in the $tag_attributes variable completely override those present in $element(html).
$tag_attributes are normally specified directly in the adp file, as attributes to a formwidget, for instance:
<formwidget id="@elements.id@" class="btn btn-outline-secondary">
Classes btn and btn-outline-secondary will be found in $tag_attributes.
The classes specified via ad_form definition are typically specified like:
...
{ok:text(submit)
{label "Test subit"}
{html {class testclass}}
{value ok}
}
...
and these will be in the $element(html) variable.
Your fix will address the case of the submit widget, but not others. As some theme packages provide the special theme classes via tag attributes, there will be many other cases where the class from the form definition is not applied.
I am working on a commit that will change the current idiom (replicated in many places) from
if { [info exists element(html)] } {
array set attributes $element(html)
}
array set attributes $tag_attributes
to
if { [info exists element(html)] } {
foreach {key value} $element(html) {
dict lappend tag_attributes $key {*}$value
}
}
array set attributes $tag_attributes
(Maybe, this should be put in some private api to have it under control)
This should make so that both definition have their fair chance to influence the result. It could also have consequences and/or generate regressions...
Will keep you posted. In the meantime, feel free to give your two cents or suggest a better solution.
All the best
Antonio
