Technology Management & Leadership

Dans tous les projets web que j’ai eu l’occasion de développer jusqu’ici, un chose est indiscutablement présente: un plan de navigation, spécifiant quelles pages mènent à quel endroit, dans quels contextes et conditions. Ces problèmes m’ont amené à développer (avec l’aide de Stéphane) et implémenter avec succès dans deux projets une méthode que je nommerai ici “Navigation Node”. Problème:

• La navigation est étroitement liée au design, donc difficile à maintenir
• Les changements de flux de navigation demandent beaucoup de tests et de vérifications
• Les URLs dynamiques sont souvent difficiles à gérer
• Il n’y a pas d’endroit centralisé ou gérer la logique de navigation

Solution:

Développer un système de nodes de navigation qui puisse “mapper” le schème fourni par les analystes en utilisabilité au système de manière simple, flexible et possiblement automatisable.

Ceci peut être fait en permettant la création de “nodes” de navigation indépendantes de l’interface utilisateur, gérées de manière centralisée.

Diagramme:

Responsabilités:

La NavigationNode devrait être implémentée pour ne contenir que la structure et la logique s’appliquant à la totalité du système, telles qu’un titre, ou l’utilisateur courant par exemple. Plusieurs implémentations de celle-ci auront la responsabilité de décrypter la requête sans pour autant contenir ni logique d’affichage ou du modèle. Une node ne devrait jamais référencer une autre node.

Le WorkflowController aura comme rôle de centraliser l’accès et la création aux NavigationNodes, tout en offrant des méthodes encapsulant la logique d’interrelations dynamiques entre les nodes.

Le ContentDisplayer n’est en réalité qu’un contrôle (UserControl dans ASP.NET) chargé par un conteneur dynamiquement grâce à la référence fournie par la node en cours du WorkflowController. Ce contrôle appellera le WorkflowController pour aller chercher la suite du flux de navigation dans son contexte, et ainsi fournir des liens ou rediriger vers une autre page après une action.

Explication: Le WorkflowController offre un accès à la node de navigation en cours. Celle ci est déterminé grâce à un paramètre de l’URL (possiblement transformée par un module HTTP), et ensuite instancié dynamiquement (selon le modèle Factory, en chargeant une collection associative à partir d’un document XML ou en utilisant un standard de nom avec la réflection*). Une fois instanciée, le WorkflowController appelle la méthode ParseQueryString, pour que la node s’auto-configure dans le contexte de navigation.

Activator.CreateInstance( Request.QueryString[“view”] + “Node” ); Cette node est ensuite utilisée pour générer le BreadCrumbs, les Tabs, le titre de la page, ainsi de suite. Des nodes peuvent être créées manuellement et utilisées pour générer des liens n’importe où dans le site, simples ou complexes. Par exemple: ProductDetailsNode.CreateForProduct( 22 ).GetUrl() Le WorkflowController peut finalement lier des nodes à des contrôles, pour permettre une navigation facilement modifiable et configurable.

Finalement, le WorkflowController pourrait parfaitement utiliser un document XML pour charger au démarrage le schème de navigation. Ce document pourrait ressembler à:

Limitations:

Certains problèmes peuvent survenir avec l’utilisation de cette méthode.

• Dans un système très large, le nombre de NavigationNodes peut vite devenir astronomique, demandant de modifier l’approche pour utiliser le les”Dynamic Navigation Node” ou “Hierarchical Navigation Node”. Ces approches seront définis ici si il y a une demande.
• Il faut penser à créer ces NavigationNodes à chaque fois qu’une nouvelle page est créée. Il peut être intéressant d’automatiser ce processus, en utilisant un groupe de dossiers comme étant les conteneurs des pages, et en roulant un script qui créerait automatiquement les nodes, ou simplement qui validerait leur existence avant un check-in ou une compilation.