Re:Re:Core - Content in filesystem?
Storing this data in the filesystem would also recreate nasty side-effects for those of us (tiki deployers) that use limited budget hosting.
On these kind of hostings, you would have next to a diskquota also a filequota. For instance, on the site I am deploying right now, it is impractical to install tiki for 3 subdomains (with their respective databases), even when I start from a same documentroot. The dq is 50MB (which I still think is enough for them to get past this year, but after installing tiki it turned out to occupy already 34MB. Adding 2 additional databases pumped it up to that amount.
But more dramatically would be the fact that they have only a filequota of 5000 files. With tiki being 3000+ files and subdirs, some site specific files and apache/php/mysql (3 times several table files!) , you can see that this leaves almost no room for template_c (for all 3), or session files for that matter. Currently am at 3900 files, and am stripping down tiki with the things I find unneeded. THAT is the biggest nightmare, because when I'm done with it, there will be a new release already ... 
So ... ease up on the nr of files. A class file (or multiple if you really need to split the functionality) and some templates is all I need. And knowing what is dependent of what and what features I do not need to be removed easily (or better yet: if I need something, I can install it
later after a minimal/core installation!)
Limit the number of entry points to tiki as well. no tiki-view_articles.php/tiki-view_wiki.php/tiki-admin_xxx.php ... have just a tiki-index.php entry point that boots up the tiki-core, gets from its parameters what object type it is supposed to display and what class is associated with it, loads that class and fires up the specified function (overridden extension) associated with the command.
Easier to maintain templates also. Let everything link back to that entry point and let it figure it out what you mean (actually, this php files is not going to get very big, since it loads the tiki-core, adresses it to see if the object exists and if the user has the appropriate rights to perform that action on it they requested. Then if the object/rights and action exist, it queries the core for the appropriate renderingclass, after which it loads it, instantiates an instance of it and executes the renderRequest()
Nothing big ... just setup and delegate ;-)
;){kind=link}
;){kind=link}