Usage of boolean config options

[Martin]

HI Gert,

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

yes, that's what I meant.

Most plugins use code like this

Code: Select all

$o .= plugin_admin_common($action, $admin, $plugin); 

- this will generate the standard form if $action == 'plugin_edit'. But of course you can write your own handling for this case ...

Martin

[cmb]

Hello developers,

But of course you can write your own handling for this case ...

I still think that it would be much effort to handle this for each plugin separatly. And it will look different for every single plugin. But IMHO it is possible to develop an "utility" plugin which offers the extended functionality for other plugins. These plugins have to require the installation of mentioned "utility" plugin, and the "utility" plugin has to come under a liberal license (e.g. GPL or freeware). But somebody has to write it. Any volunteers?

Christoph

[Martin]

Hi Christoph,

your idea for the selectboxes might be added to the current pluginloader easily without breaking compatibility. But as all variables are stored as string I guess it would be very hard or even impossible to teach the pluginloader to decide, what is the most appropriate input type for the given variable.

That's why I suggested: Keep the things like they are and offer some additional convenience functions, that handle the input creation and tooltips. After that the code for the form creation could look like this:

Code: Select all

<?php 
     pl_start_form();
     pl_input_text($var_1);
     pl_input_options($var_2, array('one', 'two', 'three'));
     pl_input_boolean($var_3);
     pl_input_textarea($var_4);
     pl_input_float($var_5);
?>
</form>

IMHO that would not be too much work for the plugin developer. And I think it's easier and less "dangerous" to add this functions than to change the given code.

Martin

Aaah, cross posting: A "plugin utitily plugin" is fine, too.

[cmb]

Hello Martin,

I guess it would be very hard or even impossible to teach the pluginloader to decide

IMHO Jerry's suggestion to use extended notation would work, e.g. "unix|windows|mac@@@1". But on further rethinking the problem, I found, that this wouldn't work well with older plugin loader versions and newer plugins using the "extended notation".

Your solution is quite nice, but still the plugin developer has to write an additional line of code, whenever he introduces a new config option.

So I would really like the "utility" plugin. It might reuse code from the plugin loader, if it will be distributed under GPL too. And I don't see any compatibility issues so far.

Christoph

[Gert]

So we will have more and more "plugins for plugins" like jQuery4CMSimple?

So you have to write in the help file and on your download page:

This plugin needs to work:

- plugin1
- plugin2
- plugin3
- ...

[cmb]

Hello Gert,

good point! So somebody could make the code available as addon, for direct inclusion to the plugin. But this will have some license problems. If every plugin should be able to use it, it has to use e.g. MIT license. But then no code from the plugin loader could be reused.

[Gert]

So somebody could make the code available as addon, for direct inclusion to the plugin. But this will have some license problems.

Hi Christoph, good idea

We can publish that code (addon) as absolutely freeware, with no license. So every plugin developer can use it. Or am I wrong?

[Martin]

... but still the plugin developer has to write an additional line of code, whenever he introduces a new config option.

So what? Of course a developer has to write code to extend his plugin. And this one single line would be the least. - And if the standard form is enough for his purposes he doesn't have to do anything at all. The auto-generator still works!

What are your ideas about the "utility"? Have you found a way to auto-create user friendly forms? Curious ...

But anyway: If we are going to enhance the pluginloader's form creation abilities - as a class or a bundle of functions - why don't we just put the new code into it's index.php?

Martin

[Gert]

And if the standard form is enough for his purposes he doesn't have to do anything at all. The auto-generator still works!

I fully agree.

There are many possibilities for the plugin developer to improve the user experience by admin.php.

And I think, it's impossible to make the standard procedure perfect for the needs of every kind of plugins.

[cmb]

Hello Gert, hello Martin,

What are your ideas about the "utility"? Have you found a way to auto-create user friendly forms? Curious ...

I've described some ideas in http://www.cmsimpleforum.com/viewtopic. ... 24&start=6. It's only addition to the current forms are optional dropdowns. But this (unfinished) solution wouln't work with new plugins and older plugin loaders.

Jerry's suggestions wouldn't break backward compatibilty, but where ugly when an old plugin loader would use a newer plugin. So I then suggested to use a utility plugin or an addon.

We can publish that code (addon) as absolutely freeware, with no license. So every plugin developer can use it.

Yes, that's right. But the addon must be developed without reusing (i.e. copying and modifying) the code from the plugin loader (as this is GPL, so any derived work has to be GPL too; and than this addon can't be used for e.g. linkware license).

But the solution would be, if Martin's suggestion where integrated to the plugin loader. So the addon could use them, and so be not too hard to be implemented. And the plugin could use an extended notation for it's strings (say an own mini syntax), possibly an extension of Jerry's ideas.

I'll report back ASAP with an idea how mentioned syntax could be.

Christoph