Ping @DenisChenu and @gabrieljenik if you're interested. We will work on this internally and initially only support global settings form and input checkbox.

Added to LS5 LTS, I guess (dev branch).

You mean : for GroupSettings ? UserSettings ? near SurveySettings

Something related to an object with an id ?

https://manual.limesurvey.org/BeforeSurveySettings
https://manual.limesurvey.org/NewSurveySettings

This would be a general event for any form that supports it. So, one form event to rule them all. :)

But : you need to review all existing form then ?

Before : need to review core form …

Each form has an id used by the event, so that objects are attached to the correct form

https://github.com/LimeSurvey/LimeSurvey/blob/baf7a27369fab4bb10bacb467790e046385da591/application/models/PluginSetting.php#L21-L22

Yeah, but we're just gonna support global settings for now. Rest are added when needed by a plugin author.

$event->append('globalsettings', new ExtendFormCheckbox('input_id', function($post, $connection) { ... save logic here }));

:(

To add 3elements

$event->append('globalsettings', new ExtendFormCheckbox('input_id', function($post) { ... save logic here }));
$event->append('globalsettings', new ExtendFormCheckbox('input_id2', function($post) { ... save logic here /* Same than previous*/ }));
$event->append('globalsettings', new ExtendFormCheckbox('input_id3', function($post) { ... save logic here /* copy/paste from previous*/  }));

I never have to update global settings ,

See how i do to create forum since some years now (and it work without update plugin …) : https://gitlab.com/SondagesPro/mailing/sendMailCron/-/blob/master/sendMailCron.php#L1403

We already hae 2 form constructor : one for Survey and one for QuestionAttribute.
You add another one …

No no.

$saveMethod = function($post, $db) { ... };
$event->append('globalsettings', new ExtendFormCheckbox('input_id', $saveMethod));
etc

We already have 2 form constructor : one for Survey and one for QuestionAttribute.

Let me read those again, then. But I doubt they are really flexible, nor object oriented...

Let me read those again, then. But I doubt they are really flexible, nor object oriented...

Not really flexible … right.

OK, so how would you add a new select2 or datepicker as a survey setting...?

Ah, it's using the SettingsWidget. Also used by plugin settings, right? I thought about that one...

Like always … «je me débrouille comme je peux»

example : https://gitlab.com/SondagesPro/OrcidAuthenticate/-/blob/master/views/admin/IntroductionSetting.php

So you'd prefer $event->append('globalsettings.tab', ...settings widget data)?

I prefer something easy and stable ;)

I think i already create a mantis issue about moving QuestoionAttributes + CoreForms + PluginSettings to same extension .

Else : i thionk have a definition array without need to create new object each time still instresting

Arrays require more writing than objects, tho. And they have no validation, or defaults. But a middle-ground is to have objects with $input->toSettingsWidget() function that converts them. Idk.

Arrays require more writing than objects, tho.

?
You mean by core team ?

And they have no validation, or defaults.

core can offer some … PluginSettings have htmlOptions and current

$saveMethod = function($post, $db) { ... };
$event->append('globalsettings', new ExtendFormCheckbox('input_id', $saveMethod));

default saveMethod by core can be great
(for example : i think i creat an issue about save Plugin settings password encrypted by default …)

Idk, the settings widget is doing a lot of shit... Starting form tags, registering css and js files, ... It should have been an object hierarchy rather, SettingsWidgetButton, SettingsWidgetBoolean, etc, instead of a function for every setting type. Then it could have been reused in different contexts.

Yes …
but : if you create another way, do you deprecated and removed old ways ?
And then : we have to redo whole plugins in 7 or 8 ?

default saveMethod by core can be great

Ya, but not sure how... xD Needs info about database table and column and validation. Basically model data.

$saveMethod = new DefaultSaveMethod('table', 'column', $validationRules);

??

but : if you create another way, do you deprecated and removed old ways ?
And then : we have to redo whole plugins in 7 or 8 ?

Urgh. No.

Why not use PluginSettings table by default ?

When i mean default : a default table + way to save.
Plugin dev can replace by it's own function.

I already use PluginSettings table to save User related data.

Urgh. No.

Then seem:s best to move (after) PluginSettings to the new ExtendForm system, no ?

We also have AdvancedSettingWidget and GeneralOptionWidget for question editor.

Already based on DTOs.

https://github.com/LimeSurvey/LimeSurvey/tree/master/application/extensions/GeneralOptionWidget/settings

Yes,
And we have 2 separate system with a lot of same code …

PS : AdvancedSettingWidget are for QuestionAttribute

Why not use PluginSettings table by default ?

Hmmm, yes, this works, true.

We also have AdvancedSettingWidget and GeneralOptionWidget for question editor.

Lack of optionnal htmlOptions (html5) and way to extend

What's HTML5 html options?

Extend how? Something else than new attributes?

Oups …
I mean any attributes : min/max for number, pattern, disabled, placeholder etc … :)

Actually, does this even need to be an event? We can have a service provider or module instead, where you can add input elements during system init. So.

// Plugin init
public function init()
{
  App()->extendedForm->append('globalsettings', new Input());
}

And then application code just fetch inputs from that service locator when needed.

Need to be in API then , not in App only.

https://github.com/LimeSurvey/LimeSurvey/blob/master/application/libraries/PluginManager/LimesurveyApi.php

Then it's clearly set it can be used without issue since API version are not updated.

Hm, yes, correct.