User tests: Successful: Unsuccessful:
Joomla! Issue Tracker [#32052] The fields "componentlayout" and "modulelayout" do not takes the class from XML
I wouldn't do that personally. IIRC, we don't define hardcoded defaults for most of the other form fields, especially one that has a system wide impact.
Yes. I don't see why use advancedSelect
.
it tricky solution related to #2018 @Bakual comment
@betweenbrain field take the any class defined in XML, and advancedSelect
if there nothing
@mbabker @phproberto so better delete the last commit?
If you want to assign a common class you should add something like jform-field
. Then field-componentlayout
for that specific item or field-modulelayout
in fact this could be generated automatically from the type so it would be fast.
That will give designers tools to customise things with:
select.jform-field {
}
or:
select.field-modulelayout {
}
And same with JS like:
$('select:not(.field-permission)').chosen();
I you don't use a default class, you're basically forcing all 3rd party extensions to edit their XML files so chosen works properly after the other PR is merged. It's a way to preveny a small B/C break without changing any behavior to the current state.
Also I think the doc for the list formfield mentions a default class "inputbox". Apparently there used to be such a default class in earlier Joomla versions. Though I didn't check that personally.
Common classes would not work in this case. advancedSelect is meant as a special class for selects where chosen or similar should be applied to. Currently it's applied to each select and you can't turn it off for a specific field. With it being the default class one could easy turn it off by applying a random class. And if nothing is given it behaves the same as now.
In my template I want the user select to be a standard select field. Why should I have a class advancedSelect
to describe a "normal" select? You should add a class the describes always the field if it's always going to be there. For example jform-select
(which IMO is wrong because you can identify select fields with the select
selector). So a field-modulelayout
really describes something that is always true.
The advancedSelect
class is linked by default to a specific behavior (chosen). So link them is a bad idea.
You know, we're talking about backend here. So unless you're talking about a backend template it doesn't impact you.
Also currently chosen is called by the extension layouts, usually with the 'select' selector. This proposed changes would make it easier, not harder to change it from a template level. The advancedSelect is in fact not linked to anything. The chosen function is linked to the class, but only if you use the default behavior without specifying a selector.
Think about it this way: an extension can mark selects as a good fit for a chosen or select2 target. And the template can then do whatever it wants with that.
ok, think better I remove the default class, in the current point ..
anyway not so difficult to set the class in the XML if need ... and we always can back to this topic when related pull will be fixed
The other PR doesn't apply a default so far.
If it gets added, then you are right, the class would be applied to a select IF no other class is given AND IF it uses the list formfield.
It would however not break anything.
@Bakual Then this never happened: Fedik@b22ac86
@phproberto You're mixing two PRs. This one had a default class intwo fields which are only used in backend. I thought your issue was about frontend. The other PR never had a default class so far.
How does use "advancedSelect" as default class work? If I don't want
advancedSelect
applied I have to define another class?