I think I've talked about this before, but here's the process of initialisation in a bit more detail.
Let's start off with a graphic. Don't worry, it looks needlessly complicated at first, but it's quite simple and I'll explain it all in detail. [img]http://shinmera.tymoon.eu/public/luminate-INIT.png[/img] First comes the user of course, who requests some page from the server. Apache takes this request and checks the URL. If it does not reference an existing file on the server, it passes it to mod_rewrite. This module allows me to make non-existent pages exist. It does that by "rewriting" the URL and sending the data to another page that I can specify. In the case of TyNET, all urls get redirected to decoder.php . Since it's a PHP file, apache will start up php and execute the file. This first calls config.php, which sets up some required base constants like database credentials, directory paths and so on. It also loads a few base classes and opens the database connection. After that, the decoder translates the url into a usable format that TyNET operate on. Simply, this means that the subdomain specifies which module to load and the rest of the path is used as arguments for the module. After this, the triggerHook function of the Loader class is called, with CORE as calling module and the subdomain as hook name. That way, modules can register whatever subdomains they want. The loader then checks all hooks that have been registered for the calling module and loads the modules associated with the hook. The loadModule function then checks if the module class file exists, if so, it checks if an instance of the module has already been created. If so, it simply returns the reference to the module and bails out. If not, it loads the class file, creates a new instance, saves the instance as a global variable (using the short variable as name), loads all the associated hooks from the db and stores them in the module, loads all modules from the required array, calls the moduleLoaded hook and finally returns a reference to the module instance. Since all modules are stored globally, they can easily be referenced from anywhere throughout the framework. I know global variables can cause a huge mess, but I don't use them for anything other than storing modules, so there shouldn't ever be any conflicts that aren't the fault of the module creator anyway. Either way, once the module is loaded, the triggerHooks function calls the function the module associated with the specific hook.
Let's make an example. The user requests the following page: http://blog.tymoon.eu/category/Bullshit There is no such folder or file on the server, so it gets passed to the decoder. The decoder sees the trigger "blog" and calls the Loader function triggerHook with the following arguments: hook="INITblog",source="CORE",destination="",args=$URLargs (So yes, the CORE is basically a module by itself as well!) The Loader now checks all the hooks that are associated with "INITblog". Usually this would be a module that provides a blog of some sort. We'll take the module from the USERSPACE for this example: Reader. It registered a hook as follows: hook="INITblog" source="CORE" destination="Reader" function="parseURL" Reader is loaded (as well as all modules it depends on) in and the function "parseURL" is called with the arguments from the decoder along. From there on it depends pretty much entirely on the module itself for what happens. Usually it'll depend on the Theme module and call its openPage and closePage functions, which create a theme and base layout, which allows for extremely easy page generation, as well as uniform layout throughout the site, if so desired. I'll get to the theme system another time though.
So yeah, I hope I could explain how the system works. You'll probably notice that this system can easily create quite a large dependency tree, which could invite quite a few problems with sloppy programming. I doubt anyone (besides me) will write modules for this in the future though, so I don't think it's much of a problem. And even so, it could be easily resolved.
A small note to finish off: Modules can register whatever hooks they want and offer whatever hooks they want. This allows a lot of flexibility, since modules can extend each other without having to fear much trouble of compatibility and so on.
Anyway, yes, I am pretty damn happy with this system and I think it's quite a good solution.
EDIT: Some changes to the system have been made that aren't reflected in the graphic above. Mainly the module class required array doesn't need to include the source path anymore.
Written by shinmera