0

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:

Zend Framework: Getting request object in bootstrap

Best way to deal with session handling in Zend Framework

(Zend version 1.9.6, not using Application nor Bootstrap)

Community
  • 1
  • 1
Julian
  • 253
  • 3
  • 14
  • It's not clear why you can't bootstrap the DB, then sessions, then do routing. Why do you need the session in order to redirect if the db is not accessible? – Tim Fountain Jul 09 '10 at 18:59
  • Because if i have an error i can't redirect. I have no direct access to the request object in the bootstrapping and although i could get it i shouldn't (that's what i've read all around). That's why i moved the db (and session) initialization code to a plugin, to be able to redirect on error. BUT those plugins get called only after the router (see the flow at http://framework.zend.com/manual/en/zend.controller.basics.html). I don't need the session to redirect on errors. At the end what i did was simply to stop using the session info in the bootstrapping. – Julian Jul 14 '10 at 20:03

1 Answers1

1

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
  • 4,842
  • 1
  • 24
  • 30
  • 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. – Julian Jul 27 '10 at 12:18
  • 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 Jul 27 '10 at 13:31