Plugins module about xoopscore HOT 7 OPEN

I've started to write this several times, and I keep getting interrupted.

A plugin manager sounds like a great idea.

First, a warning ;)

One of the first things on my list of things to do is to revamp the way modules are defined. We have way too much stuff defined in global space, and that gets in the way of growth. All the building function names with a dirname makes things ugly and awkward. PHP has classes which are great to keep things out of global space. We also have namespaces to keep class names from colliding.

Applying these to modules would give us a lot of strength. Each module gets a defined namespace. Routine pieces of code will become routine classes.

Now we load the file specified in $modversion['onInstall'] and call the 'xoops_module_update_' . $dirname function. Instead we would use the module's namespace and check for a $namespace/System/Update class, and invoke the update() method.

Instead of the current block schemes, each block becomes a class, $namespace/Blocks/$classname, that includes all of the block's pieces.

All of these classes would have defined interfaces. We end up with reusable and testable code. All of the interaction with these interfaces would get wrapped up as module environment layer, an object that all the module interactions go through. That environment would be passed in to the module code as it is run so we no longer have to depend on globals. You could work with multiple modules in the same transaction, opening up lots of new techniques.

I see a lot of benefits from this approach. That change is in the very near future.

Now, if I have not scared you off, here are some thoughts on plugins.

One of my main concerns is configuration. I loath the "copy this file here, edit this odd piece here" approach. It complicates updates, as you have to track what you can or can't overwrite. Even if you can keep track of that, you have to look for changes you might need to merge in. It isn't friendly, and it isn't acceptable.

One of the goals with the service manager, for example, was just install it, and it is ready to use. There is a similar concept in the text sanitizer now. Each extension has its own default configuration information. This is collected from each extension, and then merged with saved configuration for all the extensions. That saved configuration is in YAML, and saved in data/configs.

The extension configuration starts from a scan of the classes in the directory, but it also triggers an event allowing additional extensions to be supplied by modules.

The configuration is created when it doesn't exist. It is safe from overwrites. It can be easily edited. It can be created in advance and copied in during an install to create the desired setup as a configuration item. And it is ready to use right away.

OK, it still should have a nice GUI config tool :( But, otherwise, it a good example of how I think things should work. It is an example of the level I want us to achieve.

Please, ask questions, make suggestions. I just want us to be on the same page.

Sorry for the length.

from xoopscore.

from xoopscore.

from xoopscore.

As per usual, here are a few thoughts ;)

Waitings sounds good. Need the rss/backend, too.

I do kind of like the userconfigs plugging in to the user menu. Makes much more sense that way than as a menu item. Not sure I want that to go away. I can imagine other possible use cases.

Menus! We need improved menus.

I know we have the menus module. My issue with it is that it tries to cover too many layers. I hope to push all the presentation responsibility to the theme. A theme could choose to use the menus mod rendering, but it shouldn't be the only way.

I'd like to see some standard objects used to specify menu items and collections of menu items. I was sketching ideas in htdocs/xoops_lib/Xoops/Html/Menu -- been a while, feel free to adapt, replace or ignore. Current thinking for item properties is something like caption, link, icon class, image and tooltip text. Maybe that should be in a broader Attributes implementation (like forms) that could handle things like onclick?

Things like the system and main menu plugins should communicate with the standard menu objects.

I'd like to see menu definitions that could be expressed in multiple ways - block, nav bar section, etc. and chained together in different ways. For example, a menu could be a sub menu in another menu. With a good definition for the items, you could present them in many contexts

A way to persist a named menu is a must, but it should be possible to join that seamlessly with dynamic menus.

The current approach of editing the theme to modify the navbar menus needs to change. There is a real opportunity there.

I'm sure you can work wonders.

from xoopscore.

from xoopscore.

I proposed making a module for holding the usermenu block, so the plugins would work with this module instead of the system module.

I'm in complete agreement there. Sorry if there was confusion.

The form and html classes are already siblings. Both come from Attributes.

Forms need some extra attention because they really need to be a two way interaction.

For example, I've been considering a form enhancement (tentatively called form spec.) This would replace the old token/NONCE idea for a more defensive posture using a broader specification for the whole form. As the form is built, each field would be added to a list of what to expect as input. That would accompany the form in a hidden field as a jwt. It would be signed, know what action the form was supposed to be submitted to, and what fields should be included in the post. On the way back, instead of just checking the token, we could verify we were looking at something we sent out, that it came back to the right place, and only the fields that were supposed to be in it are processed. We could wrap the incoming data into a Request object, so the program could access the data which would match the spec all or nothing. Should make it much easier for a module to just do the right thing, every time.

I'll give naomik/htmlgen a look, but I'm not sure about dumping Smarty, just yet. You and Eduardo seem to agree on that, though :) Lots to think about.

from xoopscore.

Smarty: we could open up XOOPS for other template engines, or pure phtml, and make XOOPS more agnostic about it. Of course, Smarty could remain as the default engine, but if somebody wants to use something else, no big deal.

from xoopscore.