Utiliser plusieurs contrôleurs
Bonjours j'ai un problème avec zend, lorsceque j'essai d'utiliser un autre controlleur que le IndexController n'ai le droit à une 500 internal error et je ne sais pas pourquois.
Voici l'arborescence utilisée:
http://img150.imageshack.us/img150/1059/arbo.th.jpg
le contenu de mon .htaccess :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
| # Let's make sure that we have setup the timezone for this application,
# In some php.ini files, this value is not set. This will ensure it exists
# for every reqeust of this application.
php_value date.timezone "UTC"
# Let's also make sure that we can use the php short tag, "<?". The
# reason this is enabled is so that we can use these short tags in our
# php based view scripts. This allows for a shorter and cleaner view
# script, After all PHP IS A TEMPLATING LANGUAGE :)
php_value short_open_tag "1"
# Set the error_reporting to E_ALL|E_STRICT
# Since .htaccess only take an integer (and cannot render the PHP
# contstants, we need to find out what the integer actuall is)
#
# > php -r "echo E_ALL|E_STRICT;"
# 8191
php_value error_reporting "8191"
# The following display_*error directives instruct PHP how to display
# errors that might come up. In a production environment, it might
# be good to set these values inside the actual VHOST definiation.
# NOTE: these display error ini's should most likely be OFF
# in your production environment
php_value display_startup_errors "1"
php_value display_errors "1"
# NOTE: by setting the above php ini values, we are ensuring that
# regardless of the servers php.ini values, we can be assured that
# our application will have these set values set on every request.
# The rules below basically say that if the file exists in the tree, just
# serve it; otherwise, go to index.php. This is more future-proof for your
# site, because if you start adding more and more content types, you don't
# need to alter the .htaccess to accomodate them.
# This is an important concept for the Front Controller Pattern which the
# ZF MVC makes use of.
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L] |
mon index.php :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
| <?php
// public/index.php
//
// Step 1: APPLICATION_PATH is a constant pointing to our
// application/subdirectory. We use this to add our "library" directory
// to the include_path, so that PHP can find our Zend Framework classes.
define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/../application/'));
set_include_path(
APPLICATION_PATH . '/../library'
. PATH_SEPARATOR . '/../application/models/'
. PATH_SEPARATOR . get_include_path()
);
// Step 2: AUTOLOADER - Set up autoloading.
// This is a nifty trick that allows ZF to load classes automatically so
// that you don't have to litter your code with 'include' or 'require'
// statements.
require_once "Zend/Loader.php";
Zend_Loader::registerAutoload();
// Step 3: REQUIRE APPLICATION BOOTSTRAP: Perform application-specific setup
// This allows you to setup the MVC environment to utilize. Later you
// can re-use this file for testing your applications.
// The try-catch block below demonstrates how to handle bootstrap
// exceptions. In this application, if defined a different
// APPLICATION_ENVIRONMENT other than 'production', we will output the
// exception and stack trace to the screen to aid in fixing the issue
try {
require '../application/bootstrap.php';
} catch (Exception $exception) {
echo '<html><body><center>'
. 'An exception occured while bootstrapping the application.';
if (defined('APPLICATION_ENVIRONMENT')
&& APPLICATION_ENVIRONMENT != 'production'
) {
echo '<br /><br />' . $exception->getMessage() . '<br />'
. '<div align="left">Stack Trace:'
. '<pre>' . $exception->getTraceAsString() . '</pre></div>';
}
echo '</center></body></html>';
exit(1);
}
// Step 4: DISPATCH: Dispatch the request using the front controller.
// The front controller is a singleton, and should be setup by now. We
// will grab an instance and call dispatch() on it, which dispatches the
// current request.
Zend_Controller_Front::getInstance()->dispatch(); |
et mon bootstrap.php :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
| <?php
// application/bootstrap.php
//
// Step 1: APPLICATION CONSTANTS - Set the constants to use in this application.
// These constants are accessible throughout the application, even in ini
// files. We optionally set APPLICATION_PATH here in case our entry point
// isn't index.php (e.g., if required from our test suite or a script).
defined('APPLICATION_PATH')
or define('APPLICATION_PATH', dirname(__FILE__));
defined('APPLICATION_ENVIRONMENT')
or define('APPLICATION_ENVIRONMENT', 'development');
// Step 2: FRONT CONTROLLER - Get the front controller.
// The Zend_Front_Controller class implements the Singleton pattern, which is a
// design pattern used to ensure there is only one instance of
// Zend_Front_Controller created on each request.
$frontController = Zend_Controller_Front::getInstance();
// Step 3: CONTROLLER DIRECTORY SETUP - Point the front controller to your action
// controller directory.
$frontController->setControllerDirectory(APPLICATION_PATH . '/controllers');
// Step 4: APPLICATION ENVIRONMENT - Set the current environment.
// Set a variable in the front controller indicating the current environment --
// commonly one of development, staging, testing, production, but wholly
// dependent on your organization's and/or site's needs.
$frontController->setParam('env', APPLICATION_ENVIRONMENT);
//mise en place des layouts
Zend_Layout::startMvc(array('layoutPath'=>APPLICATION_PATH . '/layouts'));
// VIEW SETUP - Initialize properties of the view object
// The Zend_View component is used for rendering views. Here, we grab a "global"
// view instance from the layout object, and specify the doctype we wish to
// use -- in this case, XHTML1 Strict.
$view = Zend_Layout::getMvcInstance()->getView();
$view->doctype('XHTML1_STRICT');
// Chargement de la configuration
$config = new Zend_Config_Ini(APPLICATION_PATH . '/config.ini', APPLICATION_ENVIRONMENT);
// REGISTRY - setup the application registry
// An application registry allows the application to store application
// necessary objects into a safe and consistent (non global) place for future
// retrieval. This allows the application to ensure that regardless of what
// happends in the global scope, the registry will contain the objects it
// needs.
$registry = Zend_Registry::getInstance();
$registry->configuration = $configuration;
// Step 5: CLEANUP - Remove items from global scope.
// This will clear all our local boostrap variables from the global scope of
// this script (and any scripts that called bootstrap). This will enforce
// object retrieval through the applications's registry.
unset($frontController, $view, $configuration, $registry); |
donc ici j'ai essayer de reprendre le tutorial de l'authentification qu'il y a sur le site mais lorceque je veux juste tester l'affichage de la mage d'authentification via le lien http://localhost/testzend/auth/login j'ai le droit à une erreur d'appache alors que si j'accède au site normalement je n'ai aucune erreur pour le controlleur index via les liens http://localhost/testzend/, http://localhost/testzend/index, http://localhost/testzend/index/index.
Merci d'avance
edit: je viens de voir qu'il passe même pas par mon errorcontroller. Et j'ai oublier de préciser que j'ai créer un allias pour que lorceque l'on va dans le répertoire racine du site (ici le rpertoire testzend) sa pointe vers le sous-répertoire public. Peut-être que le bug viens de là.
