Posted on: 2011/9/10 13:02
Major Structural change to X2 branch suggestion...
I shared this in the developer thread and will do so here as well...
With the core we really should build 2.6 to have support for three different ways to add functionality.
By including them in 2.6 I think we will be building a way to migrate alot of current core functions to this. By migrating things out of core we can simplify the core and make it easier to upgrade in the future and outright replace with a totally new system.
The three ways to add functionality and the details on each one...
Modules: Modules include both an admin interface, user interface, also includes permissions and full access to other things as well. Basically would be what we now use as modules. I do believe we need to add 3 things to the Module system. We need a dependency system, a way to monitor when updates to a certain module are available, and bring a way to do multiple install, update etc to modules. (Like the initial install). The dependency system should prevent modules from installing without the required dependencies being the case first. And modules etc that have dependencies on them should not be allowed to be removed unless the other modules are removed first. Or will automatically disable the modules.
Plugins: Plugins should be things that are very light. They should be basically add-ons to the system that allow better functionality but don't have a user side to them. Admin plug-ins would be something that adds to the admin control panel. Such as xoopscare. You can also include anything that would be an add on that could be used by modules. Those things that have an Admin side to them to adjust them but are not stand alone and are used by modules. Things such as the Tags module would go here. You use Tags from other modules but the tags module really isn't much useful on its own. No reason why you couldn't package plugins together as well so you are not installing 30-50 plugins. This should be added to the dependency system as well ..
Libraries: Libraries would be a set of code in the form of objects that can be accessed by any module, core or plugin. These would essentially replace the framework system as we know it. There should be a core library and then support for other libraries to be added to this. There would be no limitations on these accessing the database so there should be an admin side to these as well. Even if it is a generic system that just allows installation, update and deinstallation. Essentially any function or associated data would be included in the libraries. With this in mind the add on libraries would be intended for stand alone libraries that are not already included in the core but will be maybe migrated to the core library at some point and module libraries. The Module libraries should be any and all code that does the main work for the Module. Because these would be bare objects there would be no user side or permissions etc. These would be similar to how frameworks are used now. We should also use an Autoloader system for ALL libraries except core code that wouldn't make sense as they are used constantly (Such as criteria, xoopsobject etc) . This would promote code reuse and help develop future modules more rapidly.
These are the things I am looking to program into my "uModules" project but I think they would also work very well built into the core. (I had further discussions of ideas for these and reasons for them in this thread
). I think that the current code base for the core is too bulky and tries to do too much. By putting a system like this in place for 2.6 we can then start pulling alot of the code out of the core and update it on the way. Things like the image manager, rating system, comment system etc should all be plugins. The main core API could be built into a library with this system as well. By pulling the code out and putting it into plugins and libraries we can simplify what the core is doing.
It does sound like the work being done on the XMF framework is headed in this direction and even the RM Commons stuff is going in this direction so I think it is a solid idea. I think I have expanded it out further and trying to relate it to changes we should make to the core code to support for the future.