Éléments de forme ASP.NET pages maîtresses et pages de contenu
OK, un autre obstacle dans mon projet actuel.
je n'ai jamais eu les éléments de formulaire dans les deux mon maître et le contenu des pages, j'ai tendance à avoir toutes les formes dans le contenu, le cas échéant.
dans le projet actuel, cependant, nous avons une page où ils veulent les deux. un formulaire de connexion en haut à droite, et un formulaire de questions dans le contenu.
après avoir essayé de le faire entrer, j'ai couru sur la question de ASP.NET gémissements sur la nécessité d'un seul élément de forme dans une page principale. TBH, Je ne comprends vraiment pas pourquoi c'est une exigence sur ASP.NET c'est une partie, mais hé ho.
est-ce que quelqu'un sait si/comment je peux obtenir le maître et les pages de contenu pour contenir des éléments de forme qui fonctionnent indépendamment?
dans la négative, pouvez-vous donner des conseils sur la façon de procéder pour obtenir l'apparence ou la fonctionnalité désirée?
12 réponses
pense que je vais passer en revue certaines de mes questions en suspens et voir si je peux fermer certains d'entre eux.
celui-ci était intéressant. J'ai carrément refusé de croire que vous ne pouvez avoir qu'un seul formulaire sur un ASP.NET page. Pour moi, cela n'a pas de sens. J'ai vu beaucoup de sites web qui ont plus d'un formulaire sur une page web, pourquoi un ASP.NET page en être autrement?
ça m'a fait réfléchir.
Pourquoi un ASP.NET la page besoin un élément de formulaire?
ASP.NET les pages essayent d'émuler l'environnement WinForms, par la persistance d'état fournie à travers le modèle PostBack. Cela fournit un élément d'état à un environnement sans état. Pour ce faire, l'exécution doit être capable de maintenir cet état dans chaque "forme". Pour ce faire, il renvoie des données à lui-même. Il est important de noter que:
- il n'y a rien de vraiment fantaisiste dans un PostBack.
- il utilise une forme HTTP et POST, la même que toute autre forme, à partir de n'importe quelle autre pile.
- juste parce qu'il semble qu'il pourrait faire quelque chose de spécial, son pas, tout ce qui se passe est qu'il POST est de retour avec quelques informations sur ce qui l'a causé, de sorte que vous pouvez faire des choses comme Gérer les événements côté client, dans le code côté serveur.
alors pourquoi un seul?
pour moi, C'était les millions de livres sterling question (je suis Anglaise). Je comprends que ASP.NET besoin de cela, surtout si vous utilisez ASP.NET contrôle serveur, mais pourquoi diable ne puis-je pas faire mes propres formulaires supplémentaires?
alors, j'ai pensé qu'on s'en fout, fais juste ta propre forme!
et je l'ai fait. J'ai ajouté un formulaire standard, simple avec une action soumettre de "#". Ceci effectue alors un POST à la page courante, avec les données de forme pour le forme indiquée dans la requête.
devinez quoi? Tout a bien fonctionné. Donc j'ai fini par:
- une page maîtresse, avec un formulaire HTML en
- ce formulaire permet de retourner à la page courante (essentiellement la page en utilisant le master).
- dans le code Page_Load-derrière pour le fichier principal, j'ai ensuite ajouté le code pour vérifier la requête pour voir quelles données ont été passées dans la requête. Si elle contient des données (disons un champ caché) alors je sachez que le post a été tiré du formulaire sur la page principale, si non, alors il est très liekly un PostBack du contenu, et peut être ignoré.
- j'ai ensuite entouré les étiquettes de contenu avec des étiquettes
<form runat="server" id="aspNetForm"...> </form>. Cela signifie que toutes les pages de contenu avaient automatiquement un formulaire pour travailler avec.
ceci m'a fourni une solution relativement simple et propre à mon problème. Mon formulaire de connexion fonctionne bien en tandem avec tous les formulaires de contenu créés, dont certains sont des formes complexes, d'autres utilisent beaucoup de contrôles serveur et de nombreuses Publications, et ainsi de suite.
j'espère que cela aidera les autres.
l'étiquette de formulaire elle-même est dans la page principale, comme tel, vous pouvez coder n'importe asp.net le serveur contrôle sur la page principale que vous souhaitez. Et vous pouvez écrire la logique de traitement pour ces contrôles de serveur sur le code de la page principale derrière le fichier.
ainsi, dans votre exemple, vous pouvez avoir les contrôles de connexion en haut à droite de la page maître, et ensuite avoir la logique d'authentification dans la page de code pour la PAGE maître, pas votre page de contenu.
Cela vous permet d'avoir le contrôle de connexion sur chaque page, et de maintenir ce traitement, ainsi que de maintenir les contrôles de contenu et de leur traitement sur leurs pages.
tout le monde a déjà mentionné que vous ne pouvez avoir qu'un seul élément de forme dans un donné ASP.NET page, et qu'il serait contenu dans la page principale. Pour l'instant, donc bon. Mais je ne pense pas que cela vous aide à obtenir pleinement où vous voulez être ...
dans vos pages maîtresses, vous avez (je suppose! définit 151900920 de contrôles". Vos pages qui utilisent le master ont alors les étiquettes asp:Content correspondantes. Tout le contenu de votre page doit aller dans ces asp:Content balise.
une fois dans cette étiquette, ils font partie du formulaire de la page principale. La page principale peut réagir 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, et vous êtes prêt.
si vous avez besoin de la page pour interagir avec la page principale, vous pouvez y accéder via la propriété Page.Master . Pour interagir avec n'importe quel code public-visible (méthodes, propriétés, etc.) de la page principale, vous avez jeté cette propriété à la corrigez le type, et accédez au code publiquement visible à partir de là.
Qui devrait vous obtenir où vous devez être dans ce scénario. (Cela a fonctionné pour moi sur plusieurs sites!)
Rob,
solution intéressante. Je ne vois aucun problème avec ce que vous faites. Le problème que certains peuvent rencontrer cependant, est si elles essaient de le faire avec 2 serveur de formulaires. Il n'y a pas de règle. ASP.NET que vous ne pouvez pas avoir plus d'un formulaire HTML sur une page, juste que vous ne pouvez pas avoir plus d'un formulaire "runat='server'" sur la page. Apparemment, vous avez trouvé un moyen facile de répondre à vos besoins.
j'ai constaté que pour la plupart des avec un seul formulaire n'est pas un problème parce que le ASP.NET le cadre sépare fondamentalement tout pour nous avec la dénomination des conteneurs. Mais dans votre premier commentaire post vous avez frappé sur le facteur important qui était absent mais critique pour l'essence de la question originale: entrer comportement clé. Qui toujours met des bâtons dans les œuvres.
si vous utilisiez un serveur Standard" all encompassing", ne pourriez-vous pas capturer la bonne action en utilisant un événement TextBox changed? Bien sûr, si l'Utilisateur a changé les deux valeurs avant de frapper enter sur l'une ou l'autre vous obtiendriez un comportement étrange. Et je pense que le problème de base avec la touche enter est qu'une fois que vous avez plus d'une entrée soumettre sur un formulaire HTML, frapper ENTER dans une zone de texte ne fait rien. Ce n'est que lorsqu'il y a un seul élément D'entrée que la touche enter fait "cliqué".
aucune des réponses précédentes ne donnait d'exemple de code. Voici une version simplifiée du site Visual Studio 2012.Maître qui illustre comment faire ceci:
<%@ 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 vous avez tout enveloppé par un seul élément de forme, donc vous pouvez placer des contrôles dans la page principale, mais vos pages de contenu peuvent également utiliser des contrôles.
vous ne pouvez avoir qu'un formulaire sur un ASP.NET page. Une façon de gérer cela est de mettre un gestionnaire d'événements sur le bouton login dans la page principale. 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, qui est exécuté avant les gestionnaires d'événements).
j'ai résolu le" en cliquant sur la touche de retour dans le sous-formulaire de connexion provoque le problème de formulaire principal à soumettre " dans mon projet en cours en incorporant une iframe dans la page principale. L'iframe pointait vers le login.page aspx qui authentifie l'utilisateur.
<iframe id="login" src="login.aspx" frameborder="0" enableviewstate="false" scrolling="no" runat="server"></iframe>
(forme de certains raison, j'avais besoin de la cérémonie de clôture /balise iframe sinon la vue de conception embrouillés)
vous pouvez accéder aux contrôles MasterPage à partir du formulaire aspx par: ajouter la balise deatactive au formulaire aspx < % @ MasterType VirtualPath= " ~/Site.Maître % > et dans le code derrière utiliser maître.FindControl (); pour obtenir le contrôle par ID
par Exemple, si vous voulez obtenir le formulaire de Contrôle = Master.FindControl("formulaire")
maintenant vous pouvez utiliser le formulaire de la page principale dans votre code.
j'espère que cette aide.
Salve! Dans un fil similaire, j'ai posté une réponse qui pourrait vous aider. Vous pouvez utiliser jquery pour ajouter du contenu d'une div vide. Ce contenu peut inclure des balises de formulaire, et même une fonction de soumission indépendante de tout ce que le code côté serveur fait. Le seul inconvénient est que si l'utilisateur n'a pas activé javascript!
au Lieu de reposter la même réponse (et le code aussi), voici le lien:
il s'agit d'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 cet été ASP.NET MVC, si vous êtes en mesure de je suggère d'envisager de déménager à ASP.NET MVC car elle résout un grand nombre de problèmes ASP.NET
vous pouvez avoir plus d'un formulaire. (seulement 1 visible à la fois) codeline 1 = Formulaire 1 visible / formulaire 2 cachée . Code 2 Formulaire 2 visible / formulaire 1 caché. = résolu (ce qui est idéal pour les formes de contact statique aussi bien
Non, vous ne pouvez en avoir qu'un asp.net formulaire par page. C'est la règle depuis 1.0
ils doivent tous les deux avoir la même forme