views:

28

answers:

1

Hi. I work in a project which uses the session a lot. We have a db handler (the standard one from Zend) and currently i have this initialization (db handler + session start) in a plugin for the preDispatchLoop. Previously it was in preDispatch but because of it being called for each action (included those in the 'forwarded' action, it caused me problems.

My problem is that i began working in internationalization and i began using the router to detect the language in the URI: we use the form /language/controller/action). The router would like to use the session to read/store the language. But as you may know the router comes first and then the (pre/post) dispatcher stuff.

So the question would be: why not move the session initialization to the bootstrapping ? it's because it was there before but i had to move it because i need to test that the db (remember that the session uses the db) is accessible to prevent errors. And if there's an error i simply redirect (request->setController/setAction error). If i move back the session initialization code to the bootstrapping i can't make the redirect if the db is not accessible.

I've read other question and i've found many people asking to access the request object from the bootstrapping. But they all say: you can but shouldn't. but then, how would i do in this case ? my last option would be to move back the sessions initialization to the bootstrapping and if it fails, manually send headers and read the view but the error code but that's a horrible hack.

My thoughts are that the session shouldn't be used that early. They shouldn't be called in the bootstrapping as they're not yet fully aware of the controller/action requested. I think that to get the language i could simply rely in cookies (manual) and get it from there (as well as from the URI). And if eventually some day the session info must be used in the bootstrapping i would use a global variable.

What do you think ? is there an error in the way i'm controlling the application ?

Some questions seen:

http://stackoverflow.com/questions/2622879/zend-framework-getting-request-object-in-bootstrap

http://stackoverflow.com/questions/2504884/best-way-to-deal-with-session-handling-in-zend-framework

(Zend version 1.9.6, not using Application nor Bootstrap)

A: 

I would move the session initialization and db connection to the bootstrapping.
If you can't connect to your db during bootstrapp this should count as low-level error. It is not excepted to happen in production.
Simply wrap your bootstrapping process into a try catch block so you can output an error page.

// in your index.php
try {
    $application = new Zend_Application(
        APPLICATION_ENV,
        APPLICATION_PATH . '/configs/application.ini'
    );

    $application->bootstrap()
                ->run();

} catch (Exception $e) {
    header('Content-type: text/html; charset=utf-8');
    header('HTTP/1.1 503 Service Unavailable');
    header("Retry-After: 3600");
    // Output some error page.
    echo "<html><head><title>System Error</title></head><body>...</bod></html>";
?>
Benjamin Cremer
Thanks. I also think that db and session should belong to bootstrapping but then sending headers and echoing in the bootstrap file (or any included file) is not the 'Zend way' to display an error page. And we don't have (direct) access to the request to be able to make a redirect. I have an error controller with logging, email sent and a nice view which is called there, i just wanted to make it the 'Zend way'. I think this is a chicken and egg problem.
Mr X Colombia
I use the error controller, loggin etc. too. But some errors you can't catch and handle gracefully in the "Zend Way" cause they appear to early. Think about if your application.ini is not readable. What does your application do now? So a low-level handling is required anyway.
Benjamin Cremer

related questions