Bonjour,

Je développe actuellement sous DNN 4.4.0

J'ai un module dont le contrôle principal ViewModule.ascx est définie en tant que "View" et 2 autres contrôles : ucControle1.ascx et ucControle2.ascx

Le but étant dans ViewModule.ascx d'appeler à un moment donner les contrôles ucControle1.ascx et ucControle2.ascx avec un bouton ou un lien.

J'ai voulu utilisé la méthode décrite dans la doc DNN intitulé "Navigating to a User Control in your Module" (cf. page 74 du DNN4 Module Developpers Guide)

1) J'ai donc défini mes 2 sous contrôles (uc...) dans la définition de mon module en tant que Host

2) j'ai associé la clé (key) controle1 à ucControle1.ascx  et controle2 à ucControle1.ascx 

3) le Type de mes 2 sous-contrôles est View

4) dans mon contrôle ViewModule.ascx  j'ai fait 2 boutons dont les évènements click exécutent respectivement le code suivant:

Response.Redirect(NavigateURL(PortalSettings.ActiveTab.TabID, "controle1", "mid=" & Me.ModuleId), False)

@ploum: c'est dommage de ne pas pouvoir bénéficier de cette mécanique. La notion clé/controle correspond vraiment à ce que je veux faire

De plus, si je dois utliser les placeholders il faut que je joue avec la propriétés visibles des différents contrles. Ce qui peut s'avérer fastidieux à la longue.

Salut,

je me permets de reprendre ton code, ploum, car il n'est pas correct.

la fonction GetModulesByDefinition revoit un ArrayList d'objet de type ModuleInfo: l'ensemble des instances de modules d'un portail dont la définition a le nom passé en paramètre. C'est une fonction intéressante mais ce n'est pas ce dont il s'agit ici.

ModuleId (sans rien) est équivalent à Me.ModuleId: c'est la propriété issue de PortalModuleBase qui désigne l'identifiant du module courant. C'est bien celle qui nous intéresse et l'appel à NavigateUrl produit la requète escomptée.

Au passage,

NavigateURL(PortalSettings.ActiveTab.TabID, "mygallery", "mid=" & Cstr (ModuleID)) est strictement équivalent à

Me.EditUrl("mygallery")

-> retourne la requete pour changer de controle tout en restant dans la meme page et le meme module.

Et la limitation est ici:

la classe Skin.vb, en charge de gérer les modules, appelle Globals.IsAdminControl pour déterminer si elle doit charger le module en mode standard ou en mode esclave. Le critère est la présence d'un paramètre "mid" ou "ctl" dans la requête http. Dans un tel cas, un module unique est chargé depuis ces paramètres.

Ce sont en fait tous les contrôles enregistrés dans la définition courante (une seule def par mid) avec la clé en cours qui sont chargés sequentiellement dans un panneau unique. Ceci devrait permettre au besoin d'instancier un formulaire de contrôle et un formulaire de contenu comme souhaité en combinant les clés, mais la mise ne page est restreinte et il vaut sans doute mieux au choix:

• Inclure l'ensemble de l'interface de navigation au sein des formulaires d'un module unique, avec un "header" de menu par exemple, en s'appuyant sur les actions pour  le menu principal
• Définir de multiples de définitions de module (exemple du blog), et construire pour les modules esclaves un méchanisme interne de chargement des contrôles en fonction des paramètes (la communication intermodule est également possible, mais elle n'apporte pas grand chose;  la difficulté de passer des objets entre modules est largement compensée par celle de passer des paramètres permettant de les retrouver)

Dans les deux cas, je penche plutôt pour l'utilisation de placeholders chargeant des usercontrols ou des webcontrols à celle des panels à visibilité contrôlée, sauf dans le cas d'un assistant par étapes (cf le site wizard), ou les objets metiers doivent être remplis progressivement avant la sauvegarde finale, car la gestion du viewstate en est quelque peu facilitée.

Bien sûr, y a pas de mal, effectivement ce modulecontroller orphelin est un peu étonnant. probablement un oubli.

Il s'agissait plus de poursuivre la discussion de ce thread. 

L'utilisation la plus courante d'un module controller au sein d'un formulaire de module est la récupération ou la mise à jour des Module Settings ou des Tab Module Settings selon. Cette table de paramètres s'avère bien pratique pour stocker toutes les données simples de paramétrage (pas de DataProvider a maintenir...). A Aricie, nous aimons l'abstraire derrière une structure fortement typée de paramètres serialisée à la volée, ce qui simplifie encore son accès et sa mise a jour.

Quand aux fonctions GetModuleByDefinition, elles sont beaucoup plus rarement utilisées dans un module instancié. On les retrouve souvent dans les taches planifiées ou il s'agit de retrouver tous les modules d'un certain type pour effectuer un traitement sur leurs données.

Au sein d'un module, elle sert généralement à proposer une liste de modules en sélection, dans le cadre de modules de la même famille, ou l'on va associer un module maître de contenu et un module esclave de résumé (ex du repository, ou du module private message de ventrian). L'intervention de l'utilisateur pour confirmer le choix est souvent nécessaire à cause de la possibilité de multiples instances du module obligeant à résoudre une éventuelle ambiguité.

Ce n'est toutefois pas le cas dans certains cas, comme le module de recherche admin qui utilise cette fonction directement (pas le module de recherche utilisateur) ou encore je ne sais plus quelle fonctionnalité native qui est stockée, via cette fonction, dans les moduleSettings du module de Site Settings du portail courant (on est sûr que ces modules sont instanciés une et une fois)

Voilou

Est-ce vraiment important de conserver la visibilité des autres modules de la page ?

D'après ce que tu décris, le comportement standard, qui prend l'exclusivité de la page sur l'initiation de l'un ou l'autre des workflows me paraît approprié. Un bouton "annuler" devrait permettre, via un NavigateUrl(), de retrouver l'ensemble des modules.

@Jesse: je crois que dans un premier temps je vais suivre ton conseil et appeler mes workflows sans autres modules autour (par un navigateUrl ou EditUrl)

par contre en plus du menu de base de DNN (SolPartMenu), j'ai un autre menu vertical a gauche qui est fait a partir du module tierce (LinkImage). J'aurais bien aimé conserver celui-ci.

Donc 2 possibilités :

• soit on code en dur ce menu dans le skin,
• soit on modifie le menu de base de DNN pour que d'une part il s'affiche a gauche et en vertical, mais qu'il est aussi un autre style (différent d'une treeView). A ce sujet comment fait-on pour utiliser un autre type de menu ou modifier celui de base ?

@ploum: merci pour ta référence, je n'avais pas vu que "adefwebserver" avait été remis à jour !