Plugins module

[trabisdementia]

Hi there, this module #512 requires an extra event in the core plugins class. The change was added in this commit so please review it. No need for changes in api or modules. It is as simple as install and you are good to go!

This image refers to my initial work on this module:

Unfortunately, I had to remove the "events" functionality from it because it would require major changes in the way we implement plugins. Currently we only allow one interface per module. An interface should do a simple task but for example, the system module, uses one interface for several tasks (userMenus, userPosts, waiting, backend). By disabling this interface we are disabling all the tasks. It is not possible to disable only the waiting task and leave the others running. Not possible, I mean, without major changes. It would require one interface per task and that would mean more files to lookup. It would also change the way we call for plugins because we would have to also ask for which of the module interfaces we would be interested in.

So this module does not allow to disable single events, it disables the all interface. AFAIK, the syste module is the only rule breaker! On the other end, maybe 'backend', 'userMenus', 'waiting', etc should be Jobs for other modules. The system module is doing to much :)

An upside is that it keeps thinks much more simpler to manage.

Please give it a try, I hope you enjoy it. I've tried my best to follow 2.6.0 standards.

[redheadedrod]

Please excuse if this is not the proper place for this comment but is somewhat related to this topic.

I am currently swamped with classes so I am not sure when I will be able to get involved but I did want to bring up a vision I had previously about Modules with 2.6 that I think will be very beneficial moving forward. I have some important projects coming up I need to put time into but hopefully sometime this summer I may be able to get involved again. Having said that...

Service Manager in 2.6 brings a method that will allow drastic changes to be made to module creation.
By enforcing MVC style creation of modules we can totally revamp modules into a more lightweight and universal type of application. If we consider the MVC framework we can move the Model portion of this to a Service Manager service leaving the Controller to be the meat of the module and the View would of course be the Smarty Template system we have used all along. To allow for maximum flexibility the model of a module would be broken up into serviceable models that could in essence be replaced on their own by custom models or models in other modules.

So for instance a forum module would have a bunch of small models that might include a default poll model. If you install a new poll module with compatible model then that poll module's model would be used instead. And if a newer module came out you could upgrade to using that one without affecting the original forum module.

Not sure if this has been explored and I don't know when I will have time but thought I would at least share that idea...

[geekwright]

Not something to fix, just an FYI

In XoopsTpl we register a pre-filter with Smarty that converts the '<{' and '}>' delimiters to '{' and '}'. We use the standard Smarty default delimiters now in 2.6, but still support the old way for BC.

This change, combined with the switch to the .tpl extension, makes it a little easier to use existing Smarty documentation and examples, plus template aware editors (like PHPStorm) actually work much better.

[geekwright]

Looks good --thanks!

[geekwright]

So this module does not allow to disable single events, it disables the all interface. AFAIK, the syste module is the only rule breaker! On the other end, maybe 'backend', 'userMenus', 'waiting', etc should be Jobs for other modules. The system module is doing to much :)

I agree with your "doing to much" assessment. Definitely something to consider.

[geekwright]

@redheadedrod Yes, there is a lot of movement in that direction in our future. In some cases, the plugin approach will be more efficient and a much simpler solution to implement.

This change adds some much needed controls of some of the more tightly bound connections between modules. I'll pick on search for an example. To participate in search, a module puts the code required to implement searching in its search plugin. Instead of requesting a generic service, it is providing a service using a simple predefined interface defined by another module.

By default, this works great. Install the module(s) you want, install the search module, and all the modules that have a search plugin are automatically plugged in and searchable.

This module gives us the option to break or change those interconnections. You might not want a module to participate in search, for example. With these changes, we can just turn it off without diving in and removing files from the distribution. Very cool!

[redheadedrod]

With the service manager there were plans to be able to chain things together? I am trying to think of use cases where this method would not work better than other models? If the service was chainable then you could insure the same data gets past to a service until one returns positive or some other method to check if the chain needs to continue or stop. Not sure a separate system is beneficial unless there is some major deficiency in the service manager that I am missing that can't be resolved? From: Richard Griffith <notifications@github.com> Sent: Wednesday, March 1, 2017 11:57 PM To: XOOPS/XoopsCore Cc: redheadedrod; Mention Subject: Re: [XOOPS/XoopsCore] Plugins module (#515) @redheadedrod<https://github.com/redheadedrod> Yes, there is a lot of movement in that direction in our future. In some cases, the plugin approach will be more efficient and a much simpler solution to implement. This change adds some much needed controls of some of the more tightly bound connections between modules. I'll pick on search for an example. To participate in search, a module puts the code required to implement searching in its search plugin. Instead of requesting a generic service, it is providing a service using a simple predefined interface defined by another module. By default, this works great. Install the module(s) you want, install the search module, and all the modules that have a search plugin are automatically plugged in and searchable. This module gives us the option to break or change those interconnections. You might not want a module to participate in search, for example. With these changes, we can just turn it off without diving in and removing files from the distribution. Very cool! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#515 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAmcMKm5BONNe8x_2lzIEAWc8ts-5-y-ks5rhkxGgaJpZM4MQYki>.

[geekwright]

The service manager currently only processes the first provider. There are plans to extend that, just hasn't happened yet.

This plugin system has been part of 2.6 since before I got involved. While it would be possible to implement plugins as service providers, that is really overkill. The plugins are light weight compared to service providers, kind of thumb tack vs. nail gun. They add tiny bits to sub menus, searches and similar situations.

The amount of programmer effort required is lower for the plugins, so we are more likely to have fuller featured modules if the simple things are easy plugins.