Skip to main content ↑ ↓
Topic: Modular Approach (born from removing News Fader) (Read 6661 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Modular Approach (born from removing News Fader)

Reply #15 –

@Spuds

Re: Modular Approach (born from removing News Fader)

Reply #16 –

More thoughts for when Spuds has stopped drinking beer! :P

At the moment I'm thinking at how to automatically load addons without too much hassles[1].

The first approach I had in mind was to scan the directories, load all the files with a certain naming pattern (i.e. ".addons.php" or ".integrate.php", or similar), scan for classes with a certain naming pattern, loads everything and then define what was active and what not and run only what was supposed to be run.
The advantage of this approach would be no need to store almost anything into the database, the addons by themselves would be able to determine if they are active or not and act accordingly. In addition an addond would be installed/uninstalled just by placing a file/directory at a certain place (e.g. in the sources directory or in a special directory like "integrate" somewhere).
This, tough, has a couple of drawbacks:
1) it requires a scan of the file system at each and every page load,
2) it has to load a bunch (maybe large, dunno, I know people that have some hundred of mods installed or idling into the packages directory) of files just to find out if we are using them or not.

Additionally, the "drop the file to enable the addon" may or may not be nice, so I decided to use a slightly different approach.
Like for modules (that at the moment are "things" bound to one or more specific action, like the drafts for example), there are two phases:
1) the admin area, here all the addons and modules are "loaded" to show an entry "somewhere" (most likely the packages page itself, even though at the moment I'm using core features for modules, but because they are already there...) with a toggle, that "enables" (the equivalent of the current install) the module/addon, when enabled, Elk saves the "data" (the file name and the subdirectory it is stored to) of this module/addon somewhere into the database (being lazy I'm currently using the settings table, in a second moment a standalone table can be used),
2) all the other pages, in any other page, just the enabled addons are loaded, and hooks are "registered" on-the-fly, when the file of the addon is loaded.
This way, only what is really necessary is included and is run.

I'm not sure it makes any difference in terms of speed or memory or whatever, though it looks less "bloated"[2] to me that way.
1 The concept of "without hassles" is very, very flexible and can have a lot of different meanings. :P↵
2 I wanted to used that word for a bit of show. :P↵
Bugs creator.
Features destroyer.
Template killer.

Re: Modular Approach (born from removing News Fader)

Reply #17 –

You shouldn't touch the filesystem if you don't habe to. Remember, it is the slowest part of the computer.

Make it so that it scans for people with permission to enable plugins and alerts them that there are new plugins available. Cache that and make those load from settings. Only enable plugins when an administrator says so. Require each plug in to have its own directory and make the bootstrap file either be the name of the directory which implements an interface containing a method to get the name (getPluginName) or something like "PluginBootstrap" so you're not searching for the file.

Re: Modular Approach (born from removing News Fader)

Reply #18 –

Yep, that's sort of what I'm doing, not (yet) exactly though similar.
Addons loading:
https://github.com/emanuele45/Dialogo/blob/b1a569006e307d7a1bb8de2a5ff2e7a0a7482eb3/sources/Hooks.class.php#L220
So it gets addons from "somewhere" (the database usually) and registers the hooks.
Addons "discovery":
https://github.com/emanuele45/Dialogo/blob/b1a569006e307d7a1bb8de2a5ff2e7a0a7482eb3/sources/Hooks.class.php#L260
Basically grabs anything that is named "{Something}.integrate.php" in a directory or any subdirectory and use a composer.json file (yeah, it is a bit bold on my side call it "composer", but for the moment it's just to give guidances on "good practices") to give some general informations[1].
And the discovery is used in the core features page to populate the page:
https://github.com/emanuele45/Dialogo/blob/b1a569006e307d7a1bb8de2a5ff2e7a0a7482eb3/sources/admin/CoreFeatures.controller.php#L284
1 That in the future may be used for many other things, but for now is used just for name and description.
The one "hard-coded" is there just as in case none is provided.↵
Bugs creator.
Features destroyer.
Template killer.

Re: Modular Approach (born from removing News Fader)

Reply #19 –

https://github.com/elkarte/Elkarte/pull/1950

 emanuele is out for a beer now... or two. xD
Bugs creator.
Features destroyer.
Template killer.

Re: Modular Approach (born from removing News Fader)

Reply #20 –

Question: at the moment I put all these "modules" into the subs directory. Is it the correct place to have them?
I'm asking because some of these modules use superglobals ($_GET, $_POST, $_REQUEST) and/or have fatal_errors, and stuff like that. I think I tried to minimize it, but some are likely still there.
...hmm... something to think about.
The subs directory seems correct, maybe it's just a matter of clean up a bit the things. :D
Bugs creator.
Features destroyer.
Template killer.