Chemin relatif à partir d'une commande d'utilisateur d'ASP.NET NavigateUrl

Question

J'ai un contrôle utilisateur qui contient un GridView. Le GridView possède à la fois une colonne HyperLinkField et une colonne de matrice qui contient un contrôle de lien hypertexte.

Le projet ASP.NET est structuré comme suit, avec la page Default.aspx dans chaque cas en utilisant le contrôle de l'utilisateur.

• Application Racine
  • Contrôles
    • UserControl avec GridView
  • SystemAdminFolder
    • Default.aspx
    • Edit.aspx
  • OrganisationAdminFolder
    • Default.aspx
    • Edit.aspx
  • StandardUserFolder
    • Default.aspx
    • Edit.aspx

Note:. Les dossiers sont utilisés pour assurer que l'utilisateur a le rôle correct

Je dois être en mesure de régler le DataNavigateUrlFormatString pour le HyperLinkField et le NavigateUrl pour le HyperLink pour résoudre à la page Edit.aspx dans le dossier correspondant.

Si je mets l'URL, accédez à « Edit.aspx » l'URL dans le navigateur apparaît comme ' http: // application Root / Commandes / Edit.aspx. Quel que soit le répertoire d'origine

Je ne peux pas utiliser l'opérateur racine de l'application Web (~ /) que le chemin doit être par rapport à la page en cours, pas la racine de l'application.

Comment puis-je utiliser le même contrôle utilisateur dans plusieurs dossiers et résoudre l'URL vers une autre page dans le même dossier?

Note: La question est fortement basée hors d'une question similaire par azhar2000s sur le asp forums .net qui correspond à mon problème.

Answer 1

Tout en tapant cette question que je suis tombé sur une solution possible et ont encore modifié cette rétroaction à l'aide de @Thomas.

Control.AppRelativeTemplateSourceDirectory modifie les chemins relatifs produits par le contrôle. Je l'ai mis à un racine chemin virtuel par rapport pour le courant demande le dossier. Maintenant, tous les chemins relatifs dans le UserControl avec être par rapport à la page demandée plutôt que l'utilisateur voie contrôle.

//Page Load Event for the User Control
protected void Page_Load(object sender, EventArgs e)
{
    string rootPath = HttpContext.Current.Request.ApplicationPath;
    if (!rootPath.EndsWith("/"))
    {
        rootPath += "/";
    }

    Uri requestUri = HttpContext.Current.Request.Url;
    string folderPath = requestUri.AbsolutePath.Remove(0, rootPath.Length);
    string lastSegment = requestUri.Segments[requestUri.Segments.Length - 1];
    folderPath = folderPath.Remove(folderPath.LastIndexOf(lastSegment));

    AppRelativeTemplateSourceDirectory = "~/" + folderPath;
}

Answer 2

Je le groupe en cas de charge de la grille ou la page comme ceci:

var hyperlinkColumn = this.GridView1.Columns[0] as HyperLinkColumn;
hyperlinkColumn.DataNavigateUrlFormatString = "~/SystemAdminFolder/{0}";

Cette structure suppose que l'URL doit être différente par ligne en fonction de la DataNavigateUrlField. Si elle doit être la même URL pour toutes les lignes, vous pouvez simplement définir la propriété NavigateUrl à la charge. De toute évidence, vous devez définir un autre dossier en fonction du rôle de l'utilisateur.

AJOUT Compte tenu de ce que vous avez mentionné dans votre problème dans les commentaires, ce que je suggère est le stockage de la relation rôle-dossier quelque part. Vous avez un certain nombre de choix:

1. Il suffit de stocker les clés magiquement nommées dans appSettings (Role_SystemAdministrators, Role_OrganizationAdministrators, etc.) avec le nom du dossier dans lequel ils doivent être adressées. L'avantage de cette approche est qu'il est simple. L'inconvénient est que les données doivent saisi correctement, il n'y a rien à empêcher quelqu'un de hasard un rôle cartographie à deux dossiers et quand un rôle est ajouté, il doit être mis à jour dans un autre lieu.

2. Créer un ConfigSection personnalisé pour stocker la relation. L'avantage est que vous pouvez faire en sorte que chaque rôle est mentionné qu'une seule fois. L'inconvénient est qu'il est un code supplémentaire que vous devez écrire et quand un rôle est ajouté vous avez encore ajouter quelque chose dans un autre endroit.

3. Lire les balises location sur le fichier de configuration. L'avantage est que vous pouvez éviter d'avoir à écrire une valeur dans plus d'un endroit. L'inconvénient est que faire ce sera une corvée. Il faudrait trouver la première balise associée au dossier donné sur lequel l'autorisation a été donnée utilisateur.

4. Lire les valeurs de la base de données. L'avantage est que vous pouvez facilement écrire un écran de gestion pour mettre à jour les valeurs. L'inconvénient est quand un rôle est ajouté, vous devez ajouter quelque chose à un endroit complètement différent de l'application.

Vous toujours les autorisations de dossier que vous faites maintenant. Cependant, une fois que vous avez cette relation stockée, vous pouvez rediriger la personne vers le dossier approprié sans écriture bifurcations de code personnalisé.