2010-12-14 48 views
7

Je suis coincé! J'ai l'impression que le fichier _layout.cshtml est utilisé pour le contenu de type MasterPage. Tout ce qui est rendu sur chaque page. Naturellement, je veux écrire le code pour rendre mon menu de barre latérale dans ce dossier. Je souhaite afficher de manière dynamique une liste de catégories de ma base de données, mais je n'arrive pas à transmettre le modèle de catégories à Layout.cshtml car il semble qu'aucun contrôleur ne le touche réellement.Un contrôleur peut-il influencer le fichier _layout.cshtml?

Des suggestions?

Sinon, dites-moi comment aborder ce problème. Ça fait trois jours que je me bouscule dans mon cerveau et toujours pas de solution élégante.

J'ai besoin de:

  1. une liste d'extraction Dynamiquement des catégories de la DB.
  2. Afficher cette liste de catégories sur chaque vue unique. (D'où l'utilisation de _layout.cshtml)
  3. Manipuler élégamment chaque catégories différentes cliquez.

Je suis à bout de nerfs. : P Comment résoudre ce problème?

+3

Vous avez posé un certain nombre de questions à ce sujet au cours des derniers jours, et un certain nombre de solutions ont été fournies, y compris 1) RenderPartial 2) RenderAction 3) ViewData 4) Filtre d'action globale etc. Avez-vous essayé l'un d'entre eux et comment ne répondent-ils pas à vos exigences? – marcind

+0

Cela revient à dire que le fichier layout.cshtml ne peut pas utiliser le modèle a passé car aucun contrôleur n'agit dessus. Suggestions? –

+1

@Serg, RenderAction? – jfar

Répondre

1

Tout modèle que vous transmettez à votre vue est automatiquement disponible dans votre page maître. Si vous n'utilisez pas RenderAction/Action qui est la meilleure approche, vous devez créer les données de page maîtres nécessaires dans chaque action et les ajouter aux données de visualisation - soit en ayant une classe de base commune pour votre modèle viewmodel fortement typé ou en utilisant le dictionnaire viewdata.

Je vous recommande fortement de suivre l'approche de html.action. De cette façon, vous avez une action de contrôleur totalement distincte pour gérer votre liste de catégories. Cette action peut récupérer les données de catégorie nécessaires et retourner la liste de catégories usercontrol comme une vue partielle et vous n'aurez pas à vous soucier de polluer toutes vos autres actions avec ces données.

+0

Pourriez-vous développer ce que vous voulez dire par 'html.action'? Des pages/informations sur ce que cela implique? – thecoop

+1

Ceci est une bonne intro: http://www.asp.net/mvc/videos/mvc-2/how-do-i/aspnet-mvc-2-render-action –

0

J'ai réalisé quelque chose de similaire en faisant en sorte que mes ViewModels implémentent une interface qui a des membres qui contiennent les données du menu. Dans ma méthode d'action, j'ai défini ces données. Ensuite, à mon avis, je vérifie pour voir si mon point de vue-modèle qui met en œuvre inteface, extraire les données de menu sur le menu et rendre (dans une vue partielle en fait)

1

Comme je le vois, ViewData (et ses parents comme ViewBag, modèle, etc.) est destiné à la vue actuelle spécifique. Votre _Layout.cshtml n'est pas spécifique à la vue en cours; et il serait gênant que TOUT contrôleur doive transmettre les données de catégories en plus de toutes les autres données qu'il doit transmettre pour la vue. Au lieu de cela, ce que je fais, est de fournir une méthode statique dans une de mes classes auxiliaires qui récupère les catégories de la base de données. Je fais aussi de la mise en cache là-bas, de sorte que je n'ai pas besoin d'appuyer sur la base de données pour chaque requête. La disposition.cshtml appelle simplement cette méthode statique. Simple et élégant.

Si vous le souhaitez, vous pouvez faire ressortir cela en vue partielle, en faire une méthode d'aide, peu importe. Une note de prudence cependant - ma vue d'erreur personnalisée utilise également le même _Layout.cshtml, et si la base de données tombe en panne, vous obtenez une exception en essayant d'afficher l'exception. ASP.NET MVC est suffisamment intelligent pour détecter ce problème et annuler le traitement, mais il vous reste une page d'erreur par défaut non définie. Ce que j'ai fait était de placer des instructions try...catch autour de ces appels dangereux, qui ignorent silencieusement l'exception si la page en cours est la vue d'erreur.