-
-
Save weierophinney/2243840 to your computer and use it in GitHub Desktop.
<?php | |
return array( | |
'modules' => array( | |
'Application', | |
/* ... */ | |
), | |
'module_listeners' => array( | |
'use_defaults' => true, /* false to disable them */ | |
/* list additional module listeners to use here */ | |
), | |
'module_listener_options' => array( | |
'config_cache_enabled' => false, | |
'cache_dir' => 'data/cache', | |
'module_paths' => array( | |
'./module', | |
'./vendor', | |
), | |
'instance_manager_configuration_key' => 'configuration', | |
), | |
'instance_manager_class' => /* named instance manager here */, | |
); |
<?php | |
chdir(dirname(__DIR__)); | |
require_once (getenv('ZF2_PATH') ?: 'vendor/ZendFramework/library') . '/Zend/Loader/AutoloaderFactory.php'; | |
Zend\Loader\AutoloaderFactory::factory(); | |
$appConfig = include 'config/application.config.php'; | |
$application = new Zend\Mvc\Application(); | |
/* Next line would: | |
* - instantiate the requested instance manager | |
* - ensure all modules are initialized | |
* - instantiate and attach the default listeners, if using them | |
* - these could potentially be pulled from the instance manager | |
* - these _might_ be passed the instance manager -- this would simplify the | |
* workflow of the configuration listener | |
* - instantiate and attach the requested listeners, if any | |
* - same notes as above | |
* - the configuration listener would inject the configuration into the | |
* instance manager at the requested key | |
*/ | |
$application->bootstrap($appConfig); | |
$application->run()->send(); |
'application_class'
is redundant, because we manually instantiate app with new Zend\Mvc\Application();
.
re: "application_class" -- missed that in the last revision; fixed now.
re: send() -- your comments actually prove to me why we need it. The send() method is what you'd overwrite in order to perform anything other than the default. run() does something with the request, send() determines what to do with the response.
send()
method lives in Response
-- you're still missing the point. Give any type of response, there are n
ways to handle it. "Sending it" is just one option.
Why force it in a "dummy init file" which is index.php ?
What you are proposing implies that the only way to change how ZF2 application handles response, is to hijach the mvc process, and create a subclass for each possible strategy - i.e. class HttpResponseBeingSent
, class HttpResponseToFile
, class ConsoleResponseToStream
, class HttpResponseCachedAndThenSent
etc. That's absurd. Why do we use MvcEvent at all, when we could subclass Mvc\Application
20 times to implement all strategies and their combinations. (unless you see some other sneaky way of doing what I've brought up)
ps: it was the first thing I removed when building sample Console application, because the response not always reaches the console window, or it's not always of "Console\Response" class. It might land elsewhere, return an exit code and send to error stream or do a thousand other things (which should live within respective strategies).
Can we finally remove
->send()
from index.php?It's up for the application (and listeners + strategies) to decide whether to send the response, save it to file, save it to db, send to proxy, discard, pass on to job server or queue man etc...