Usage of boolean config options

[svasti]

Hi fellow plugin developers:

Development of the core is now in the hands of Martin and Gert, and I guess, we all can suggest ideas. Although this feature is not that important, it would definitely be nice to have.
I would prefer to leave the choice of check box, radio or combo to the plugin developer. (Hey, I like to have choices.)

What about backward compatibility?
Not all CMSimple sites are up to date. Therefore a plugin asking for combo or whatever in the config, shouldn't crash an old CMSImple. May be there could still be

Code: Select all

$plugin_cf['my_plugin']['my_feature']="1"

plus something which wouldn't disturb the old CMSimple, but which could be used by newer versions to make boxes etc. instead? One could use a new variable name in the config file, like

Code: Select all

$plugin_cfx['my_plugin']['my_feature']['my_box_preference']="1,2,3"

The present CMSimple would ignore it and kill it on saving. Doesn't matter, the old style config variables are still there. A new version could take the new variables into account.

svasti

[cmb]

Hello svasti,

Development of the core is now in the hands of Martin and Gert, and I guess, we all can suggest ideas. Although this feature is not that important, it would definitely be nice to have.

We all can suggest ideas, but we could try to put a solution together, and suggest, that this will be included. I think it's not too hard to implement Jerry's suggestion. But I definitly would like a solution for options in $plugin_cf.

Hey, I like to have choices.

Yes. IMO the user likes to have choices too So I would like an option in $cf (for all plugins) so the user could configure, if he likes dropdowns or radios. He is the one who has to work with it.

Christoph

[jerry]

No matter what it will be there is also need for muliple choices.
jerry

[cmb]

Hello Jerry,

there is also need for muliple choices

Do you mean that several options will need a dropdown, or that a single option will need a <select multiple>? IMHO the first case is important, but I don't see the need for the second case.

And I've thought about your idea using JS. IMHO it could be possible to have a separate plugin, handling all this with JS only. But if the plugin isn't installed, the user has to fiddle around with the special notation.

I guess everything could be handled from the plugin loader as well.

Christoph

[Gert]

Development of the core is now in the hands of Martin and Gert

But not because we have decided so, but because it has evolved so

We are glad to see, that some more people are interested now. And we were glad, if there would be some more developers offer ideas and solutions.

It is no problem, to extend the core a little bit, to provide some more possibilitys for plugin developers, but consider:

- extend, but not change the core. All things (or the most) also should work the old way.
- what ever is possible to realize as a plugin, should be realized as a plugin.

And: We like ideas - but we love solutions

----------------------------------------------------

At the moment we have the tooltips for help the user to set the right config parameters. Advantage: It's multilingual, because created from the language files.

It's not enough to give the user the Choice by a select box, it should be explained by a multilingual tooltip furthermore. So it will be more work for the plugin developer, but also more comfort for the user.

I'm not really sure, if it is worth to do that work. But if there is a really easy to integrate and backward compatible solution - why not.

[Tata]

At the moment we have the tooltips for help the user to set the right config parameters. Advantage: It's multilingual, because created from the language files...it should be explained by a multilingual tooltip furthermore...

I would probably prefere to separate the tooltips into their own files. Still, the tooltip is an excellent helptool and it shall be kept its way. But if the tootips would be organized in their own files, these files would be accessible via a link, so the user would have "syntax and settings owerview" on one place. ANd the tootip-variables would still be usable in admin.php or index.php or whatever file will the plugin use.
I also think that the idea to have basic syntax examples e.g. on Main Plugin Settings TAB would help a lot.

[Gert]

I would probably prefere to separate the tooltips into their own files.

I don't think so. The language files are the right place for multilingual tooltipps.

But if the tootips would be organized in their own files ... so the user would have "syntax and settings owerview" on one place.

The user can have the overview, if he calls the language file in the plugins menu. All "$plugin_tx['the_plugin']['cf_...]['...']" variables are shown in one block named "cf".

That's what I mean with:

- extend, but not change the core. All things (or the most) also should work the old way.

[Martin]

Hi,

it's true: The forms created automatically by the plugin loader offer a poor user experience.

My first thought was: Hey, of course it's very convenient for a plugin developers to have the configuration and language forms auto-generated - but we don't have to stick to it! Under some aspect it might be regarded as some fallback or shortcut to be used during the development. It's our responsibility to make things more user friendly: We can create individual forms for our plugins and use radio boxes, select inputs and all the other stuff that is common for web interfaces. (We do not have to bother the user with the possibility to edit our help texts as well.) Just don't use the restricted "plugin_admin_common" to have the forms created for you, if the result is not sufficient! Don't be lazy! Create your own!

But maybe it's a good idea to offer some functions (like "pl_input_boolean($cf_var_name); pl_input_options($cf_var_name, $options_array);" or so) to make
things easier and assure a homogeneous look and feel?

Martin

[Gert]

Hi Martin,

have some problems to understand, I know, my English is not the best

Just don't use the restricted "plugin_admin_common" to have the forms created for you, if the result is not sufficient! Don't be lazy! Create your own!

Do you mean, the plugin developer should use the admin.php to make the plugin administration more user friendly?

Then I would agree

[cmb]

Hello Martin,

Don't be lazy! Create your own!

It is possible to do so, but that would increase the huge amount of work for every single plugin. The plugin author has still lots of things to do but coding the pure solution (documentation, testing, perhaps 2 languages etc). But in very special cases, I agree, that the plugin author should use his own function instead of plugin_admin_common().

assure a homogeneous look and feel?

That was my point, in bringing the idea to the forum. The current way of let plugin_admin_main() handle the configuration is a good way IMHO, so the user will not be confused by totally different displays in the back-end. But I really would like to have an extension of the current way allowing at least dropdowns.

Christoph