[eluser]ntheorist[/eluser]
I'm wondering if anyone has tried writing config files using php, versus using a db call to get basic page info, and if that would even make an impact on performance etc. I'm not talking specifically about db result caching, but more for template/layout/page settings (or more specifically settings to be loaded on controller/method basis)
i'm thinking of file setup such as
APPPATH / config / site / {controller} / {method} .php
also you would have
APPPATH / config / site / {controller}.php
and
APPPATH / config / site.php
which could cascade and override settings as you move to the method (you could have a dir for method parameter uri segments too )
each file would simply hold an array for basic data. Template to use, css files, javascript links, basic access restrictions etc.
It would allow for some features: titles could be stacked, page assets can be tracked, and a cms could separately manage the xhtml files and save config arrays from the database, or even opened and written by hand. Plus they could be re-used for purposes such as ajax calls super easy with no db queries. ie return json_encode(get_page_config($controller,$method))
anyway i see a lot of benefits, but some pitfalls. Namely complexity, and i'm not sure if file reads are much better than querying the database. The intention is to be able to produce 90% cached files in flat php and the system simply combines the cofig array with the page, calling up the db only when needed, and delivers it. It's also not meant to override the controller in anyway (aside from a site_controller that extends controller, containing the assembly code), more to clean it up, reduce db calls yet keep your pages dynamic, and allowing you to remove methods that are redundant (ie those that simply set a few vars or load a view file )
anyone second this idea, tried it with any success or know a class that does this?
thx,
_n_
