7
Quote:
Each module should provide it's own interface to its't database and perhaps even it's display functions.
During install, this code should be registrated or collected into some central XOOPS file. With every new module installed, the registration or file should be rebuild.
Daigoro, you are right. That's more or less the same approach Postnuke used.
If someone wants to know more, there is a
document on hooks in PostnukeSome more...
Every module should register all the functions it can provide.
We can define some of them as
mandatory to assure a minimum layer of use and integration (getVersion, getItem, getProvidedFunctions...let's think about them...)
Every module MUST assure that it doesn't need any other module to successfully execute those functions (or, otherwise, there must be a way to know that it will fail...and discover loops!)
"Hooks" system will be provided in php code AND in smarty functions, to assure intermodule operation (in particular for raw access to the content) and for easy templating (formatted HTML Smary-tagged content, registered via
$smarty->register_object() function)
We must be careful about how to call modules function, because we don't want different modules loaded at the same time with conflicting namespaces.
I will post more informations about how PN solved this problem...
Ok, enough for now to write about... I'll post more info later.