Radio options case changed #930

New Issue

Closed

opened 2022-07-09 16:43:50 +00:00 by Chris Paschen · 1 comment

Chris Paschen commented

2022-07-09 16:43:50 +00:00

Member

Steps to reproduce the issue

Create a radio field
Set options to:

1|A B C ...,2|1 2 3 ...,3|a b c ...,4|I II III...,5|i ii iii ...

(using this to give outlining options)

Compile & Install

Expected result

Options should display as:

[A B C ...] [1 2 3 ...] [a b c ...] [I II III...] [i ii iii ...]

Actual result

Options display as:

[A B C ...] [1 2 3 ...] [A B C ...] [I II III...] [i ii iii ...]

similarly, if you have the first option set to "a b c" then the 3rd option becomes "a b c".

Seems that something is automatically adjusting the case of the options.
(Although the 4th & 5th options, roman numerals, are never chagned)

System information (as much as possible)

OS Name & Version: WAMP
MySql Version: 5.7.31
Apache Version: 2.4.46
PHP Version: 7.4.9
Joomla Version: 3.10.10
JCB Version: 2.13.1
Browser: Firefox Developer

Additional comments

It appears to be the way that JCB is 'interpreting' the entries there and changing them both to language constant:
COM_COMPONENT_A_B_C_

Which I understand why this is happening (and know how to work-around this*) but wondering if there is a more 'gracefull' way to handle this so that lowercase doesn't always get converted just to upper case.

Maybe need to check the options to make sure that we don't use the same constant twice in one radio field (because you'd never need to have two options of the same thing).

BTW ... in case anyone runs into this, one solution was to just add "d" to the second set of alpha which made it change enough to be recognized.
I eneded up naming each one a logical name in the field config (upperalpha, numeric, loweralpha, upperroman, lowerroman) which creates unique contsants and then just dealt with it in translation.
(BTW ... the language strings are created in the administrator/COM_COMPONENT/models/forms/VIEWNAME.xml ... for anyone looking to do this via the translation method)

### Steps to reproduce the issue Create a radio field Set options to: 1|A B C ...,2|1 2 3 ...,3|a b c ...,4|I II III...,5|i ii iii ... (using this to give outlining options) Compile & Install ### Expected result Options should display as: [A B C ...] [1 2 3 ...] [a b c ...] [I II III...] [i ii iii ...] ### Actual result Options display as: [A B C ...] [1 2 3 ...] [A B C ...] [I II III...] [i ii iii ...] similarly, if you have the first option set to "a b c" then the 3rd option becomes "a b c". Seems that something is automatically adjusting the case of the options. (Although the 4th & 5th options, roman numerals, are never chagned) ### System information (as much as possible) - OS Name & Version: WAMP - MySql Version: 5.7.31 - Apache Version: 2.4.46 - PHP Version: 7.4.9 - Joomla Version: 3.10.10 - JCB Version: 2.13.1 - Browser: Firefox Developer ### Additional comments It appears to be the way that JCB is 'interpreting' the entries there and changing them both to language constant: COM_COMPONENT_A_B_C_ Which I understand why this is happening (and know how to work-around this*) but wondering if there is a more 'gracefull' way to handle this so that lowercase doesn't always get converted just to upper case. Maybe need to check the options to make sure that we don't use the same constant twice in one radio field (because you'd never need to have two options of the same thing). * BTW ... in case anyone runs into this, one solution was to just add "d" to the second set of alpha which made it change enough to be recognized. I eneded up naming each one a logical name in the field config (upperalpha, numeric, loweralpha, upperroman, lowerroman) which creates unique contsants and then just dealt with it in translation. (BTW ... the language strings are created in the administrator/COM_COMPONENT/models/forms/VIEWNAME.xml ... for anyone looking to do this via the translation method)

Chris Paschen commented

2022-07-09 16:52:25 +00:00

Author

Member

So, feel free to just close this if you also think so.
(No need to spend time fixing something that has a better 'user-entry' fix than a code-fix).

But having this here might help someone in the future.

After working with this a bit, maybe it's 'more proper' to do this via the language strings and translation, as I just realized using 'upperalpha' and 'loweralpha' makes the component much more 'robust' to more easily handle translations (and making the translation process a bit easier for the translator). So, feel free to just close this if you also think so. (No need to spend time fixing something that has a better 'user-entry' fix than a code-fix). But having this here might help someone in the future.

👍 1