This raises the question of whether ant or phing should be used as part of this project. I don't use them, but if shown the advantages I will jump on board. It may be too complex for a basic example -- perhaps we could show examples of plain and with phing sauce.Maugrim_The_Reaper wrote:Zend_Config allows division of a single config file - easy enough to categorise configuration categories. The development vs production difference is slightly different - one is defunct and even a little dangerous if allowed in production. Admittedly I'm a fan of ant and Phing so you can guess my answer involves dual files, one with the notorious .dist extension part, the other being deleted before being pushed to a production server. Outside that - separate files and manual replacement should be enough. Plus a sprinkling of hard-coded controls to prevent errors (triggered by the production server's IP perhaps).
I'd be interested to see the benchmarks. I don't think simplest is necessarily best. I think we want something that follows a clear convention, and is flexible and powerful enough. Maybe our simplest case is not the simplest implementation, but it should be clear what is going on and you can do anything you want config wise.Maugrim_The_Reaper wrote:Zend_Config doesn't care whether the file is PHP, INI or XML. YAML support is outstanding (I'm pushing for it). Someone benchmarked which was faster recently - I'll try digging up the reference. INI is the simplest though. I'd start as simple as possible - let it evolve as needed and we can re-visit a cleaner method if required.
I think the reason I asked is that there was an example of selecting config by IP address. That is outside the capabilities of the Zend Confg system. As is doing things other things, that's why I suggested using a PHP file rather than one of the data file formats. It also means you only need to load Zend_Config rather than the other config classes. And you could always load a data file from the config.php. It also means that there would probably be a config var that could be accessed directly in index.php -- rather than the overhead of fetching back from a config object. I am just trying to get to a solution that is performant, works in the most cases, and is easy to understand.Maugrim_The_Reaper wrote:Path to config files? I prefer convention where possible for a single Path. Easier for Phing to work it's magic. In general I always prefer convention and automation to most other options for these decisions - I know "building" PHP sounds OTT, but it's a simple exercise in defining what's supposed to happen to turn subversion tags into production ready code, automating those steps, using the automation to integrate frequently (testing) and continuing to celebrate your obvious laziness as a programmer
. A basic Phing config file is only a few lines long for a config replacement/renaming task.
The same idea goes for where the bootstrap config file lives. If it is outside the application directory that may make code updates easier. I'm just trying to find a solution that follows a straightforward convention, is flexible, and allows as much config information as possible to be bootstrapped for use in index.php and beyond.