? Success

User tests: Successful: Unsuccessful:

avatar Fedik Fedik - open - 20 Sep 2013
avatar betweenbrain
betweenbrain - comment - 20 Sep 2013

How does use "advancedSelect" as default class work? If I don't want advancedSelect applied I have to define another class?

avatar mbabker
mbabker - comment - 20 Sep 2013

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.

avatar phproberto
phproberto - comment - 20 Sep 2013

Yes. I don't see why use advancedSelect.

avatar Fedik
Fedik - comment - 20 Sep 2013

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?

avatar betweenbrain
betweenbrain - comment - 20 Sep 2013

@Fedik I think it it best to not assign any class if none if designated. Not all elements need a class and enforcing one by default is not ideal if you ask me. It is a more future proof approach to leave them blank.

avatar phproberto
phproberto - comment - 20 Sep 2013

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();
avatar Bakual
Bakual - comment - 20 Sep 2013

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.

avatar Bakual
Bakual - comment - 20 Sep 2013

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.

avatar phproberto
phproberto - comment - 20 Sep 2013

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.

avatar Bakual
Bakual - comment - 20 Sep 2013

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.

avatar Fedik
Fedik - comment - 20 Sep 2013

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

avatar phproberto
phproberto - comment - 20 Sep 2013

@Bakual backend? What happens if a field with the class is loaded in frontend? Not modulelayout or componentlayout but the rest of fields modified in #2018

All the fields will be adding a class that doesn't describe them.

We have to use the correct markup in frontend & backend.

avatar Bakual
Bakual - comment - 20 Sep 2013

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.

avatar phproberto
phproberto - comment - 20 Sep 2013

@Bakual Then this never happened: Fedik@b22ac86

avatar Bakual
Bakual - comment - 20 Sep 2013

@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.

avatar Fedik
Fedik - comment - 8 Feb 2014

pull to staging #3070

avatar Fedik Fedik - close - 8 Feb 2014

Add a Comment

Login with GitHub to post a comment