RFC: Modules and Extensions

I've given a lot of consideration to modules, and have a few ideas I want to present. If you have comments, alternatives, objections or other feedback, please respond. Baring objections, I would like to move on this quickly.

Namespaces

Add a namespace column to system_module table. This would be the PHP namespace for the module's code. It would map to the module's class directory in PSR-4 fashion. This would be implemented automatically for all active modules with a namespace specified.

Note, this will be separate from the composer maintained loader, since composer has no way of knowing if a module is "active" in XOOPS. Autoloading components from modules which are not installed or inactive could create lots of issues.

With the namespace enabled, most of the old directory positional naming constructs can be replaced with objects. For example, instead of using the $modversion['onInstall'] entry to locate a file to include, then building function names based on the module name, the code would look more like this:

if (class_exists($moduleNamespace . 'System\Install')) {
    $install = new $moduleNamespace . 'System\Install;
    $success = $install->postInstall($module);
}

Our current preloads directory, with possibly multiple files, would disappear, and everything would reside in the$moduleNamespace . 'System\Events' class instead.

In this scheme, the class/System directory would be reserved for the system specified classes. Each would have a specific interface defined.

There are more details, but this should illustrate the concept.

Modules vs. Extensions

Based on some thoughts from @bitcero and some more consideration, I propose eliminating the extension concept as is, and moving to a module category system to make management cleaner.

Categories would be something like this:

Category	Usage
Content	articles, blogs, calendars, forums, etc.
Developer	module builders, schema tools
Extension	service providers, system enhancement
Locale	i18n resources, language packs
Theme	for the new module based themes

This is not carved in stone, but the idea is to create a limited, high level taxonomy to categorize modules. The defined categories would be enforced, as we don't need a free for all. The module listing functions would be adapted to deliver lists of individual categories.

A category column on the _systemmodule table would hold this item. To support subtle differences, each category would be backed by a sub class of the system module class, but all would offer the same functionalities.

Add a modinfo column to system_module

Caching of the $modversion array has been suggested many times. Adding a single column set on install and update can accomplish this, and the existing getInfo() and related methods will be able to use the column data as the source, eliminating the need to hit the filesystem.

With this information in the database, all the module object access can be fully cached, which should speed thing up a bit.

Looks good to me...

I will add that with my time with Drupal 7 the modules (including core modules) use categories and they are probably more of your "free for all" concept and is something I mentioned in the past. but it works quite well. With an add on for Drupal you can collapse the categories so you just have a list of the ones you are looking for. Yes if you have some modules installed it becomes a long list but personally I think it works very well. Here is a screen shot from a site I take care of:

Note that at the top there is an area that shows a status message for available updates (Will say everything is up to date or will point out there are modules that need to be up dated) There are tabs which will allow you to update modules that have updates and an uninstall tab that allows you to uninstall modules that have been disabled.

This just shows part of the "core" category and a few modules that are installed. Note the first column is checked if the module is enabled. With Drupal if a module has been added to the module directory then it has been installed. When it is enabled then it is "installed" like they are on Xoops. If you disable the module then it is still installed just as it is in xoops. The big difference is that with Drupal (in my experience so far, but maybe I am wrong) when you uninstall a module you are just removing its database entries. It is still included on the MODULES listing here but there is nothing in it until you enable it which then installs it in the system.

This then shows the name of the module, the version, a short description of the module. The description portion also includes a dependency portion that shows any dependencies required or recommended for the module and if they are installed and/or enabled.

With drupal as shown in this screen shot you also can also show any HELP, Permission settings or Configure options to select on.

As I said it is very nice and works well. The ONLY issue I have seen with it is that the lists tend to get long but you can collapse the category. There is an enhancement for drupal that allow you to remove much of the information included as well. The enhancement has a switch instead of the check box and looses much of the rest of the information. I find myself using the information so I leave the original version enabled.

If you play with Drupal at all you will note that a module may actually install many modules under more than one category. This is useful for installing plugins that use the modules that are part of the module package and allows easy enhancements.

With Drupal they actually separate most modules into more than one module for easy of turning off portions you don't need as well. One concept I have seen over and over is that a lot of modules will have a UI portion and a standard portion. A more complex module may have MANY modules as part of the system and have modules that help enhance other categories as well. The UI modules generally are ADMIN menus for the module and if you want to further secure your site you can disable or even remove the UI modules in many cases which would make it very difficult for someone with admin access to modify settings for the module.

And yes that simple site I showed has probably 10 pages of modules if you list them all. But it works well and is very informative. I do hope Xoops in the future has something similar. I do find it hard to come back to Xoops admin system after Using Drupals. They still have a configuration menu as you can see from the screen shot but for the modules this design is the best I have used and as I already mentioned I hope Xoops can use something similar.

Richard,

1) Namespaces

this makes perfect sense. The only suggestion I would have is to be consistent with plurals in our folders and DB. For example, we have plurals in:

/assets
/blocks
/docs
/images
/modules
/templates
/tests
/themes

but we have singulars in:

/class
/language

and now in the DB we have: system_module. Since we're listing several modules, a plural "system_modules" seem to me more natural and consistent.

I would also change /class and /language to plurals

2) Modules vs. Extensions

This also makes perfect sense, now that we have Service Providers.

3) Add a modinfo column to system_module

That makes sense. You might also take a look at the Preference class created by Dugris in his Xoo-Modules, e.g. here. I feel that we should be looking for ways to reuse certain aspects of Preference configurations, e.g. elements related to Image management, like image/thumb size, file size, etc. so we don't have to type the same thing in all modules. Maybe you have already something in mind that would make it a nice OOP way of creating and reusing config values.

1) Regarding singular vs. plural, for the first time I am aware of, all system tables are consistent -- singular, just like the backed object. The basic argument is the table is always a collection of some object, and the naming of the the container is by convention (in US English, at least) a singular construct. As an example, I have a tool box, not a tools box.

It really comes down to which way you look at it. From the collection of objects view it is tool box. From the other end, the SQL select perspective, it is a more natural construct to select from tools. In the end, it is divisive issue, but I went with singular. Not worth a holy war - that work is done, and internally consistent.

There is a certain amount of historical baggage we will end up carrying in folders, so the best we can do is to be consistent in movement as we progress. The pattern for folders is, as you point out, overwhelmingly plural.

The language folder is well on the way to being dead, and for BC only. We can move to classes for base in the new namespaced standard.

3) For preferences, it makes a lot of sense for the complex arrays in xoops_version to move to classes, where inheritance becomes a possibility, so that is already on the radar. For blocks, for example, my thinking is one object per block, each based on a single interface. The xoops_version list would become a list of block implementer object names, and each of those objects would have a standard method to expose the default definition, a method for form editing and a method for rendering. Since they are objects, they can easily use inheritance.

Configurations would get a similar solution. There are several areas for improvement there, so I will keep your observations in mind.

Thanks for the feedback!

I would just use

if (class_exists('xoops\modules\system\Install')) {
    $install = new xoops\modules\system\Install;
    $success = $install->postInstall($module);
}

And XoopsLoad would look for the class in private folder and in public folder. Easy way to start removing modules from the public directory. I'm for using convention over configuration here. Don't see a need for modules to dictate their namespace.

XOOPS / XoopsCore