Usage of boolean config options

[cmb]

Hello developers,

I stumbled across boolean config options. As all config options must be stored as strings, I wonder what's the best why to check for those options? In cms.php I found the test == 'true'. Is this the common way to handle it? I wonder if the admin will not stumble across it by e.g. using TRUE.

Another possibility might be PHP's implicit type cast. Then only the empty string and '0' will be treated as false, everything else as true. That might not be the best way either. An explanation by $tx or $plugin_tx is additional effort, and might be overlooked in the latter case.

Should perhaps a new function be included to the core's API, which will handle those cases?

Any comments appreciated,
Christoph

[jerry]

Or an extention of configuration file to include possibility of dropdowns, so the end user can choose between hardcoded values. I know it's tricky but it's the most user friendly solution. And it will solve any problems with fields that have even more options.

All the plugins I know read the values ​​as non-case sesitive, so it's not a problem
jerry

[Holger]

Should perhaps a new function be included to the core's API, which will handle those cases?

Hmm, for booleans I've switched to use = 0 / 1 as possible options in the configuration.

Holger

[cmb]

Hello jerry,

Or an extention of configuration file to include possibility of dropdowns, so the end user can choose between hardcoded values

Great So a plugin developer doesn't have to write too much hints in $plugin_tx about possible option values in $plugin_cf. But it has to be integrated to the plugin loader.

All the plugins I know read the values ​​as non-case sesitive, so it's not a problem

Thanks for this information; seems to be a viable soltution.

Christoph

[svasti]

Hi developers,

what do you think about the next version of pluginloader having the additional possibility of option values, radio boxes and check boxes? May be the pluginloader could be triggerd in a certain way to display boxes etc for certain items in the config menu?
Most users are used to check boxes, they are unaccustomed to filling in "true" or "1".
May be it could be put on the wish list?
I'd rather prefer to do all the config of Calendar Plugin with radio and check boxes. That would be much more intuitive. Actually I'd prefer radio boxes to option values.

svasti

[cmb]

Hello Frank,

what do you think about the next version of pluginloader having the additional possibility of option values, radio boxes and check boxes?

I would like selections (aka comboboxes) and checkboxes. IMO radios will waste too much space in the config display.

Or an extention of configuration file to include possibility of dropdowns, so the end user can choose between hardcoded values

I've thought about Jerry's suggestion. I think it is possible to implement this, without breaking backward compatibility. Consider:

Code: Select all

$plugin_cf['myplugin']['line_endings'][0] = "unix";
$plugin_cf['myplugin']['line_endings'][1] = "unix";
$plugin_cf['myplugin']['line_endings'][2] = "windows";
$plugin_cf['myplugin']['line_endings'][3] = "mac";
 

So the plugin loader has to check, if the config option is an array. If it is, the chosen option has key 0. The other keys are the values the user could select from (by using a combobox or radios; perhaps this could be a config option in $cf). Checkboxes (boolean values) could be used by

Code: Select all

$plugin_cf['myplugin']['line_endings'][0] = "true";
$plugin_cf['myplugin']['line_endings']['boolean'] = "true";
 

So the plugin loader must check first if the key 'boolean' exists. If so, a checkbox will be displayed, with the value of key 0.

But: all this must be implemented, and I don't know, how much work that'll be, and how important it really is. But I would like to have this feature for better usability.

Christoph

[cmb]

Hello Frank, hello developers,

based on my given assumptions about extending $plugin_cf to for a selection of options, it wasn't hard to adjust the plugin loader to display it.

Code: Select all

@@ -582,8 +582,19 @@
                 else { $var_name = (isset($hint['cf_'.$key]) AND !empty($hint['cf_'.$key])) ? '<a href="#" class="pl_tooltip">'.tag('img src = "'.$pluginloader_cfg['folder_pluginloader']. '/css/help_icon.png" alt="" class="helpicon"').'<span>'.$hint['cf_'.$key].'</span></a> '.str_replace("_", " ", $key).': ' : str_replace("_", " ", $key).':'; }
                 $saveform .= '<tr>'."\n".'<td '.$style['tdconfig'].'>'.$var_name.'</td>'."\n".'<td>';
                 $style_textarea = $style['input'];
-                if(strlen($value)> 50) { $style_textarea = $style['inputmax']; }
-                $saveform .= '<textarea '.$style_textarea.' name="'.$pluginloader_cfg['form_namespace'].$key.'" rows="1" cols="40">'.$value.'</textarea>';
+                if (is_array($value)) {
+                    $saveform .= '<select name="'.$pluginloader_cfg['form_namespace'].$key.'size="1">';
+                    for ($iii = 1; $iii < count($value); $iii++) { // $iii to avoid name clashes
+                        $saveform .= '<option';
+                        if ($value[$iii] == $value[0])
+                            $saveform .= ' selected';
+                        $saveform .= '>'.$value[$iii].'</option>';
+                    }
+                    $saveform .= '</select>';
+                } else {
+                    if(strlen($value)> 50) { $style_textarea = $style['inputmax']; }
+                    $saveform .= '<textarea '.$style_textarea.' name="'.$pluginloader_cfg['form_namespace'].$key.'" rows="1" cols="40">'.$value.'</textarea>';
+                }
                 $saveform .= '</td>'."\n".'</tr>'."\n";
             }
             $saveform .= '</table>'."\n"."\n";
 

Just a quick hack as proof of concept. Now the "only" parts missing are a way to get the options posted back, and to save them in PluginPrepareConfigData().

Christoph

[cmb]

Hello Holger,

sorry, I've overlooked your post so far

Hmm, for booleans I've switched to use = 0 / 1 as possible options in the configuration.

Until there is a possibility in the plugin loader to display combos/radios/checkboxes, I guess that might be the best solution. TRUE and FALSE may sound strange to the user (YES and NO might be better). But a common way to handle this with all plugins and the core would be best IMO.

Christoph

[jerry]

What about a dropdown list like

Code: Select all

plugin_cf[plugin_name][something]="option1,option2,option3@@@2"

That means a list with 3 elements and a selection pointer after @@@. In this example 2 = option3. The pluginloader must check for existence of @@@ to know it is a dropdown and handle it like this. On selction the value of the pointer must be changed wich can be done trough javascript. It can't handle checkboxes and radio buttons but a dropdown should be enough to handle selections.

it will be in CMSimple spirit, simple.

[Edit] corrected closing " in code example.

jerry

[cmb]

Hello Jerry,

my suggestion was based on the assumption, that backward compatibility must be remained. But I think your suggestion won't bring any problems in this regard. JS in the backend will be no problem too. And saving the post values will work without change. I will think about it, but on first thought, it sounds good and simple

Christoph