By putting these settings first they cannot use config setting to set error reporting -- such as on for development site but off for the live site. Should they set after config is defined?
Again, because this is before the configuration information a separate variable is used. That also means that the path cannot be changed by the config.
Assuming configuration contains such settings, then yes, they should be placed there. I simply hadn't messed with configuration yet since it's a slightly softer subject - there are a dozen and one ways of handling transition from a development to a production environment and this was the simplest for now. It would be better to have something in config settings.
I have started to see date_default_timezone_set() in many demos. What are the pros/cons of having this setting explicit? Is it required or a php.ini setting?
I think it should be removed, but a warning note added. The problem is very few users typically check INI settings and this has never cropped up prior to 5.1 as anything more than an obscure issue. Now using system settings raises E_STRICT errors if it's not set. It really doesn't belong in the application code...
Two questions. First is whether the search path should just go to "/application" and then when you want a model you do "models/MyModel.php" or for misc code you do "inc/MyCode.php". Second is whether we should have have this Incubator/Core stuff still? Will it be necessary to stay current or is it just an artifact of the 0.1 - 0.9 process?
I think the path setting is important because it defines conventions within the program code. So it would be good to thing about the ramifications of different settings. I also leads to the question of whether to use _autoload()?
There is some convention setting attached - using "./application/models" assumes a further convention ruling Model class names and filepath - likely a non-issue until there's actually a Model class to load
. So it can be stripped out until needed? Incubator and Core simply recognises that the Framework proposal procedures always place stable code in Incubator pending at least one full release cycle. I don't think it's essential for a demo app though.
Is this needed or should this be either hard coded or come from the config data? I don't currently do this kind of processing in index.php because it is a set-once-and-it-works value.
If hard-coded it's not flexible - which becomes an issue for how the application is installed, esp. if a widely distributed application. It's also by definition a user variable, so it should be sanitised for every request. If nothing else it trades a little performance for a little consistency in what future developers get for using it unpredictably.
You use the fluent syntax as opposed to standard method calls. What do people prefer? Is there a performance difference?
I used the fluent interface because it's reasonably clear, and as far as I know has no performance downside. It's a personal preference only.
There are some more details about the response that we will probably need to get into later. A big one is whether there is an outer View object that is defined here in index.php?
Possibly, but some recent changes around Views and the Response object, I think, make it less needful. What exists has already grown a lot of extra functionality likely to cover the majority of needs. If something more is required it will become more obvious as things move on.
I am not sure which way is better. I think I would prefer to keep the rules as simple as possible and add additional .htaccess files (with "RewriteEngine off" in it) where you don't want rewriting. The "/public" seems nonstandard to me.
The problem I have is relying on numerous .htaccess files everywhere where one could suffice. Sticking in public is just a simple device - any other directories can be tagged as needed with clearer naming, or even more specialised rules.
Again, I am not sure I like the non-standard "/webroot/public" and /application/user" directories. A separate directory for config files does make sense. I am also wondering about the whole "/library" path. Things could almost be simplified by just putting everything into "/application". It is not as though it will get that that cluttered. An "/Zend" could be a symbolic link. So maybe something like:
Example looks fine - don't let me quibblin' derail ye