Improved plugin modularity

[andrewscaya]

Hello @mchurchward,

I'm currently working on a project for a university in Canada, and we were wondering if the mod_questionnaire project is open to getting rid of some of its hard-coded switches and constants that define the question types in a couple of places in the plugin's code (locallib.php and the question class), and replace them with a "registry object", which could be accessible through a new triggered event (Event API), once the module's initialization phase is completed. Since the configuration of the question types is already saved in one of the database tables, it would simply be a question of adding maybe two more fields to it, in order to store a FQCN and a template name for each question type. This would allow projects to extend the question types from other plugins (local plugins, for example), while avoiding to modify the code of this plugin, or having to apply patches on each upgrade (more easily maintainable code over time).

Are there any chances that such a PR would get merged? If so, we would have something for you very shortly.

Many thanks in advance!

Andrew

[mchurchward]

Hmmm.... I'm not completely sure I understand, but refactoring the questionnaire is an on-going concern. Perhaps you could provide more information on what you are thinking?

[andrewscaya]

OK. Maybe we can start with a PR that keeps everything as is, except for the new FQCN column in the question_type table (with some minor code changes without changing the API of the plugin). This would allow for other plugins to extend mod_questionnaire, by simply using this new configuration feature. I'll make sure everything is still running smoothly (including the unit tests). We'll keep the registry object (and maybe some new admin settings for our FQCN column) for a future PR. Would this be fine with you?

[mchurchward]

Sure. But I would still like to understand more about the registry object,

[andrewscaya]

OK. We would have to 'include' an init script on all entry points of the plugin, and send out two (or more) events during the initialization phase: one would be pre init, and one post init. We would include a reference to the registry object in the event. Thus, any other plugin could listen in, and grab the registry object to change the questionnaire (questions, templates, etc.) on the fly (ad hoc).

The registry object itself would be a typical Registry (service manager type of object - cf. https://martinfowler.com/eaaCatalog/registry.html) that would allow devs to dynamically generate/modify questionnaires, and store them in it (could even be done using Closures, like it is the case for other registry components - please see \Pimple\Container).

This is my proposal, and I'm obviously open to discuss this further.

Many thanks!

P.S. Here is example of this type of Registry object (our PHP framework - LightMVC - uses the Pimple Container object to do so): https://lightmvc-framework.readthedocs.io/en/latest/services.html#service-manager.

[andrewscaya]

Hello @mchurchward,

I've sent a first PR pertaining to the first aspect of our proposal, which was greater OOP extensibility for mod_questionnaire.

#457

I've removed the structures (switches, constants, etc.) in order to make question type loading (including response types and templates) more dynamic. Any FQCN can now be included in the added field in the database. This way, it is now possible to extend mod_questionnaire in another plugin (local, for example), without modifying this plugin's code.

Of course, this is more of a POC, than a final version of the code. I'm therefore open to discussion.

Finally, adding a registry object could be the next step in making mod_questionnaire more event-driven.

Many thanks for your time!

Best regards,

Andrew

[andrewscaya]

Hello @mchurchward --

Any updates on this PR? Is it an idea that is worth exploring any further?

Many thanks!

Best regards,

Andrew