Éléments de formulaire dans les pages maîtres ASP.NET et les pages de contenu
OK, une autre route dans mon projet actuel.
Je n'ai jamais eu d'éléments de formulaire dans les deux mon maître et les pages de contenu, j'ai tendance à avoir tous les formulaires dans le contenu, le cas échéant.
Cependant, dans le projet actuel, nous avons une page où ils veulent les deux. Un formulaire de connexion en haut à droite, et un formulaire de questions dans le contenu.
Ayant essayé d’intégrer cela, je suis tombé sur la question d’ASP.NET qui se plaignait du besoin d’un élément de formulaire unique dans une page maître. TBH, je ne comprends vraiment pas pourquoi il s’agit là d’une exigence de la part d’ASP.NET, mais hé ho.
Est-ce que quelqu'un sait si/comment je peux obtenir que les pages maîtres et de contenu contiennent des éléments de formulaire qui fonctionnent indépendamment?
Si non, pouvez-vous donner des conseils sur la façon de procéder pour obtenir le look/fonctionnalité souhaité?
Je pensais pouvoir revoir certaines de mes questions en suspens et voir si je pouvais en fermer certaines.
Celui-ci était intéressant. J'ai carrément refusé de croire que vous ne pouvez avoir qu'un seul formulaire sur une page ASP.NET. Cela pour moi n'avait aucun sens. J'ai vu beaucoup de pages Web qui ont plus d'un formulaire sur une page Web, pourquoi une page ASP.NET devrait-elle être différente?
Alors, ça m'a fait réfléchir.
Pourquoi une page ASP.NET nécessite-t-elle un élément de formulaire?
Les pages ASP.NET tentent d'émuler l'environnement WinForms en conservant la persistance d'état fournie par le modèle PostBack. Cela fournit un élément d'état à un environnement sans état. Pour ce faire, le moteur d'exécution doit pouvoir conserver cet état dans chaque "formulaire". Pour ce faire, il enregistre des données sur lui-même. Il est important de noter que:
- Il n'y a pas vraiment de fantaisie dans un postback.
- Il utilise un formulaire HTTP et POST, le même que tout autre formulaire, à partir de toute autre pile.
- Ce n’est pas parce qu’il semble qu’il s’agit de faire quelque chose de spécial que tout ce qui se passe est que POST est de retour avec quelques informations sur sa cause. Vous pouvez ainsi gérer des événements tels que le côté client, dans le code côté serveur.
Alors pourquoi un seul?
Pour moi, c'était la question à un million de livres (je suis britannique). Je comprends que ASP.NET en a besoin, en particulier si vous utilisez des contrôles serveur ASP.NET, mais pourquoi diable ne puis-je pas créer mes propres formulaires supplémentaires?
Alors, j'ai pensé foutre le boulot, juste faire ta propre forme!
Et j'ai fait. J'ai ajouté un formulaire simple et standard, avec une action "#". Ceci effectue ensuite un POST sur la page en cours, avec les données de formulaire pour le formulaire donné dans la demande.
Devine quoi? Tout a bien fonctionné. Alors j'ai fini avec:
- Une page maître, avec un formulaire HTML en
- Ce formulaire est renvoyé à la page en cours (essentiellement la page utilisant le maître).
- Dans le Page_Load code-behind du maître, j'ai ensuite ajouté du code pour vérifier la demande afin de voir quelles données étaient transmises dans la demande. Si elle contient des données (disons un champ caché), alors je sais que la publication a été obtenue à partir du formulaire de la page maître, sinon, il s'agit très probablement d'une publication de contenu, et peut être ignorée.
- J'ai ensuite entouré les balises de contenu avec des balises
<form runat="server" id="aspNetForm"...> </form>. Cela signifiait que toutes les pages de contenu avaient automatiquement un formulaire avec lequel travailler.
Cela m'a fourni une solution relativement simple et propre à mon problème. Mon formulaire de connexion fonctionne correctement avec tous les formulaires de contenu créés, dont certains sont complexes, d'autres utilisent de nombreux contrôles serveur et de nombreux PostBacks, etc.
J'espère que cela aide les autres.
la balise de formulaire elle-même se trouve dans MasterPage. Vous pouvez ainsi coder n’importe quel contrôle serveur asp.net sur la page maître de votre choix. Et vous pouvez écrire la logique de traitement de ces contrôles serveur sur le code situé derrière le fichier de la page maître.
Ainsi, dans votre exemple, vous pouvez avoir les contrôles de connexion en haut à droite de la page maître, puis la logique d'authentification dans la page de code pour la PAGE PRINCIPALE, pas votre page de contenu.
Cela vous permet d'avoir les contrôles de connexion sur chaque page et de gérer ce traitement, ainsi que de gérer les contrôles de contenu et leur traitement sur leurs pages individuelles.
Rob,
Solution intéressante. Je ne vois pas de problème avec ce que vous faites. Cependant, le problème que certains peuvent rencontrer est qu’ils essaient de le faire avec 2 formulaires de serveur. Il n'y a pas de règle dans ASP.NET selon laquelle vous ne pouvez pas avoir plus d'un formulaire HTML sur une page, mais simplement que vous ne pouvez pas avoir plus d'un formulaire "runat = 'serveur'" sur la page. De toute évidence, vous avez trouvé un moyen assez simple de répondre à vos besoins.
J'ai constaté que, pour la plupart, le traitement d'un seul formulaire ne pose pas de problème, car le framework ASP.NET sépare fondamentalement tout pour nous avec les conteneurs de nommage. Mais dans votre commentaire initial, vous avez souligné le facteur important qui était absent mais essentiel à l’essence de la question initiale: saisir le comportement clé. Cela jette toujours une clé à molette dans les œuvres.
Si vous utilisiez un formulaire de serveur standard "englobant", ne pourriez-vous pas capturer la bonne action à l'aide d'un événement de texte modifié de zone de texte? Bien sûr, si l’utilisateur modifiait les deux valeurs avant d’appuyer sur Entrée, vous obtiendriez un comportement étrange. Et je pense que le principal problème de la touche Entrée est qu’une fois que vous avez plus d’une entrée de soumission sur un formulaire HTML, appuyer sur la touche Entrée dans une zone de texte ne fait rien. Ce n'est que lorsqu'il y a un seul élément INPUT que la touche Entrée en provoque le "clic".
Tout le monde a déjà mentionné que vous ne pouvez avoir qu'un seul élément de formulaire dans une page ASP.NET donnée et qu'il serait contenu dans la page maître. Jusqu'ici tout va bien. Mais je ne pense pas que cela vous aide à aller pleinement où vous voulez être ...
Dans vos pages maîtres, vous avez (je suppose!) Défini les contrôles asp:ContentPlaceHolder. Vos pages qui utilisent le maître ont alors les balises asp:Content correspondantes. Tout le contenu de votre page doit aller dans ces balises asp:Content correspondantes.
Une fois dans cette balise, ils font partie du formulaire de la page maître. La page maître peut répondre aux événements à partir de ses propres contrôles, et les pages elles-mêmes répondent aux événements à partir de leurs propres contrôles.
Si vous souhaitez que la page interagisse avec la page maître, vous pouvez y accéder via la propriété Page.Master. Pour interagir avec tout code visible publiquement (méthodes, propriétés, etc.) à partir de la page maître, vous devez attribuer le type approprié à cette propriété et accéder ensuite au code visible par le public.
Cela devrait vous mener là où vous devez être dans ce scénario. (Cela a fonctionné pour moi sur plusieurs sites!)
Aucune des réponses précédentes n'a donné un exemple de code. Voici une version simplifiée de Visual Studio 2012 Site.Master qui explique comment procéder:
<%@ Master Language="C#" AutoEventWireup="true" CodeBehind="Site - Copy.Master.cs" Inherits="WebApplication1.Site1Master" %>
<!DOCTYPE html>
<html>
<head runat="server">
<title>This is a title</title>
<asp:ContentPlaceHolder runat="server" ID="HeadContent" />
</head>
<body>
<form runat="server">
<header>
<div class="content-wrapper">
<div class="float-right">
<section id="login">
<asp:LoginView runat="server" ViewStateMode="Disabled">
<AnonymousTemplate>
<asp:ContentPlaceHolder runat="server" ID="AnonContent" />
</AnonymousTemplate>
<LoggedInTemplate>
<asp:ContentPlaceHolder runat="server" ID="LoggedInContent" />
</LoggedInTemplate>
</asp:LoginView>
</section>
</div>
</div>
</header>
<div id="body">
<asp:ContentPlaceHolder runat="server" ID="FeaturedContent" />
<section class="content-wrapper main-content clear-fix">
<asp:ContentPlaceHolder runat="server" ID="MainContent" />
</section>
</div>
</form>
</body>
</html>
Ainsi, tout est entouré d'un seul élément de formulaire. Vous pouvez donc placer des contrôles dans la page maître, mais vos pages de contenu peuvent également utiliser des contrôles.
Vous ne pouvez avoir qu'un seul formulaire sur une page ASP.NET. Une façon de gérer cela consiste à placer un gestionnaire d'événements sur le bouton de connexion de la page maître. Le gestionnaire validera l'utilisateur et redirigera vers la même page en cas de succès (pour exécuter correctement le gestionnaire Page_Load exécuté avant les gestionnaires d'événements).
Vous pouvez accéder aux contrôles MasterPage à partir du formulaire aspx de la manière suivante: Ajoutez la balise detractive au formulaire aspx <% @ MasterType VirtualPath = "~/Site.Master%> Et dans le code après utilisation Master.FindControl (); pour obtenir le contrôle par ID
par exemple si vous voulez obtenir le Formulaire de contrôle = Master.FindControl ("formulaire")
vous pouvez maintenant utiliser le formulaire de la maquette dans votre code.
J'espère que cette aide.
J'ai résolu le problème "En cliquant sur la touche de retour dans le sous-formulaire de connexion, le formulaire principal est soumis" dans mon projet actuel en incorporant un iframe dans la page maître. L'iframe pointait vers la page login.aspx qui authentifiait l'utilisateur.
<iframe id="login" src="login.aspx" frameborder="0" enableviewstate="false" scrolling="no" runat="server"></iframe>
(forme une raison pour laquelle j'avais besoin de la balise de fermeture/iframe sinon la vue de conception devenait confuse)
Baume! Dans le même fil, j'ai posté une réponse qui pourrait vous aider. Vous pouvez utiliser jQuery pour ajouter du contenu à un div vide. Ce contenu peut inclure des balises de formulaire et même une fonction de soumission indépendante de tout ce que fait le code côté serveur. Le seul inconvénient, c’est que si l’utilisateur n’a pas activé javascript!
Au lieu de republier la même réponse (et le code aussi), voici le lien:
Ceci est une limitation de ASP.NET
ASP.NET est conçu pour avoir un formulaire par page et un seul formulaire. Quand il a été conçu à l'origine, ce n'était pas un problème.
Cependant, depuis lors, cela a été identifié comme un énorme problème d'accessibilité.
Microsoft Fix pour cela était ASP.NET MVC. Si vous le pouvez, je vous conseillerais de passer à ASP.NET MVC car cela résout un grand nombre de problèmes avec ASP.NET