J'ai du mal à mettre en place Zend_Navigation
des fils d'Ariane avec des paramètres d'URL dynamiques.
Scénario simple : imaginez un CompanyController
avec un viewAction()
qui prend un id
de l'URL pour obtenir des informations sur une entreprise particulière.
URL: example.com/company/view/id/4
Desired breadcrumb: Home > Companies > [ Company name ]
J'ai fait quelques recherches en ligne et j'ai trouvé la solution suivante : dans une predispatch()
crochet je prends le id
paramètre de $_SERVER['REQUEST_URI']
(nous ne pouvons pas utiliser l'objet de requête pour cela puisque la distribution n'a pas encore commencé) et récupérer cet enregistrement dans la base de données. Ensuite, j'ajoute simplement cette page à sa page racine dans le fichier Zend_Navigation
récipient. Vous pouvez en voir l'implémentation au bas de cet article.
Le problème que j'ai trouvé avec cette approche est qu'elle n'est pas évolutive :
-
Et s'il y a plus d'une action pour chaque entreprise ?
En dehors de
view
l'enregistrement de l'entreprise, nous pourrions également vouloiredit
(example.com/company/edit/id/4
) ou d'effectuer d'autres actions sur elle. Bien sûr, nous pourrions créer une instruction de commutation pour vérifier l'action à partir de l'URL, mais je pense que ce n'est pas évolutif. -
Que faire s'il y a plus d'un paramètre dynamique dans l'URL ?
Pour chaque
company
nous devons également gérer soncontacts
(le propriétaire de l'entreprise, le responsable des finances, etc.ContactsController
qui détient également unviewAction
yeditAction
. Comme un contact est directement lié à une entreprise, nous voulons que cela se reflète également dans l'URL et le fil d'Ariane :URL: example.com/company/company-id/4/contacts/contact-id/2 Desired breadcrumb: Home > Companies > [Company name] > Contacts of [Company name] > [Contact name]
Nous pouvons facilement mettre en place une route pour cela. Mais maintenant, nous devons récupérer plus d'un fichier
id
de l'URL. Ce processus peut être sujet à des erreurs au fur et à mesure que les URL deviennent plus complexes.
Jusqu'à présent, j'ai trouvé deux solutions plausibles :
-
Prolonger le
Plugin_Navigation::preDispatch()
crochetUne solution possible serait d'utiliser des paramètres URL verbeux (comme
company-id
ycontact-id
). De cette façon, nous pouvons extraire le nom (iecompany
) et récupère l'enregistrement par le biais de la classe de modèle correspondante. -
Ajouter les pages au conteneur de navigation dans nos méthodes d'action
Ce serait l'option la plus flexible, je pense, mais cela signifie également que nous ne pouvons plus gérer nos miettes de pain à partir d'un point central, ce qui est un sérieux inconvénient.
J'ai fait un certain nombre de recherches, mais il ne semble pas y avoir de solution toute faite pour ce problème. Toute aide serait très appréciée.
El Plugin_Navigation::preDispatch()
crochet mentionné plus tôt :
class Plugin_Navigation extends Zend_Controller_Plugin_Abstract
{
public function preDispatch()
{
$view = Zend_Controller_Action_HelperBroker::getExistingHelper('ViewRenderer')->view;
$config = new Zend_Config_Xml(APPLICATION_PATH . '/configs/navigation.xml','nav');
$container = new Zend_Navigation($config);
$urlParts = explode('/', ltrim($_SERVER['REQUEST_URI'], '/'));
$pos = array_search('id', $urlParts);
if ($pos !== FALSE)
{
$id = $urlParts[$pos + 1];
$model = new Model_Company();
$company = $model->fetchOne($id);
$rootPage = $container->findOneBy('controller', 'company');
$rootPage->addPage(new Zend_Navigation_Page_Mvc(array(
'controller' => 'company',
'action' => 'view',
'label' => $company->name
)));
$view->navigation($container);
}
}
}
Quelques références sur ce sujet :