Well, the best way to learn what I've done to directory structure is
browsing the new trunk tree
The most important changes in
Modularization Stage One are:
- Modules now reside in modules directory rather than system/core
- Every module can have a full set of necessary files in its folder: lang, tpl, img, etc. It can have its own functions.php and resources.php file. But all these are optional, you are not forced to use them all.
- Names of include files are shortened, the duplicate part is removed. So, now it is modules/forums/editpost.inc.php instead of system/core/forums/forums.editpost.inc.php. Langfile names are also shortened, so English forums langfile is modules/forums/lang/en.lang.php
- There is a lang folder in root with subfolders by language. These are core langfiles (main, countries, skin) which are shared between all modules.
- The APIs have been split into files too. It's a bit pity but functions.php does not contain many thousands of lines with all the functions you would need ever. It contains very basic functions and functions used everywhere. Logically separate and consistent APIs now have their own files located in system folder: cache, debug, email, extrafields, tags, uploads. The number of APIs will grow and there will be less dependencies (low coupling), so that Cotonti becomes more like a CMF.
The uncomfortable thing about APIs is that you have to require them explicitly. So, if you need file uploading functions in your module or plugin, then you'll have to require them:
require_once sed_incfile('uploads');
- Currently the number of explicit includes has grown, some implicit includes (like xtemplate.php) have become explicit. It results into more code but less hidden dependencies and unused code overhead. Probably, a better way saving you time coding will be presented later.
- Admin module has its own default skin. So you don't need to implement admin part in your skin if you don't really want to. Actually, every module now has support for its default template (useful for third-party modules shipped with default templates), but admin module has its own header/footer.
The
Modularization Stage Two means implementing APIs for automated module and plugin management. So that you can drop the modules in as easy as plugins.
